feat(cli): name the machine on the approval page - #1828
Open
Conversation
Member
Author
|
This pull request is part of a Mergify stack:
|
Contributor
Merge Protections🔴 3 of 7 protections blocking · waiting on 👀 reviews and ⛓️ dependency
🔴 ⛓️ Depends-On RequirementsWaiting for
This rule is failing.Requirement based on the presence of
🔴 👀 Review RequirementsWaiting for
This rule is failing.
🔴 🔎 ReviewsWaiting for
This rule is failing.
Show 4 satisfied protections🟢 🤖 Continuous Integration
🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 📕 PR description
🟢 🚦 Auto-queueWhen all merge protections are satisfied, this pull request will be queued automatically. |
The approval page defaulted every token to "Mergify CLI", the client name every machine shares, on a page whose own helper text asks the user to name it after the machine. `auth login` now sends the hostname as the `device_name` field of the grant request, so the default reads "Mergify CLI on work-laptop" and a user with a laptop, a desktop and a devbox can tell three tokens apart on the CLI Tokens page. The bare hostname, not a composed label: the server composes `<client name> on <device name>` itself, so sending "Mergify CLI on host" would render "Mergify CLI on Mergify CLI on host". Nothing is trimmed, lower-cased, or cut to length on this side. The server sanitizes the value — printable ASCII, collapsed whitespace, 60 characters — and caps the label it composes, and a client that pre-trimmed would only disagree with what the page then shows. The field is optional and the machine may have no answer, so `machine::name()` returns an `Option` and the field is omitted rather than sent empty: a grant without it is what every client sent until it existed, and the server keeps its own default for one. The name comes from `hostname(1)`, which ships on all three platforms and stays right when the name changes under a running shell, falling back to `COMPUTERNAME` / `HOSTNAME` for a container that has no `hostname` on `PATH`. No new dependency for it. A hostname can carry a person's name, and this sends it to the API. It is shown in an editable field on the approval page before anything is stored, so the user sees the value and can change it in the moment they are already looking at that page. Fixes MRGFY-9262 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Change-Id: I7e2ec96a405831003ab0eb03e2a9208f2e7db5d8
sileht
force-pushed
the
devs/sileht/mrgfy-9262-cli-login-ux/open-browser-auth-login--90e2ca4c
branch
from
September 11, 2026 16:00
65c58ec to
15ef21b
Compare
sileht
force-pushed
the
devs/sileht/mrgfy-9262-cli-login-ux/name-machine-approval-page--7e2ec96a
branch
from
September 11, 2026 16:00
33a4e8e to
fc4baeb
Compare
sileht
had a problem deploying
to
func-tests-live
September 11, 2026 16:00 — with 
GitHub Actions
Error
GitHub Actions
Error
Member
Author
Revision history
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The approval page defaulted every token to "Mergify CLI", the client
name every machine shares, on a page whose own helper text asks the
user to name it after the machine.
auth loginnow sends thehostname as the
device_namefield of the grant request, so thedefault reads "Mergify CLI on work-laptop" and a user with a laptop,
a desktop and a devbox can tell three tokens apart on the CLI Tokens
page.
The bare hostname, not a composed label: the server composes
<client name> on <device name>itself, so sending "Mergify CLI onhost" would render "Mergify CLI on Mergify CLI on host".
Nothing is trimmed, lower-cased, or cut to length on this side. The
server sanitizes the value — printable ASCII, collapsed whitespace,
60 characters — and caps the label it composes, and a client that
pre-trimmed would only disagree with what the page then shows.
The field is optional and the machine may have no answer, so
machine::name()returns anOptionand the field is omitted ratherthan sent empty: a grant without it is what every client sent until
it existed, and the server keeps its own default for one. The name
comes from
hostname(1), which ships on all three platforms andstays right when the name changes under a running shell, falling back
to
COMPUTERNAME/HOSTNAMEfor a container that has nohostnameon
PATH. No new dependency for it.A hostname can carry a person's name, and this sends it to the API.
It is shown in an editable field on the approval page before anything
is stored, so the user sees the value and can change it in the moment
they are already looking at that page.
Fixes MRGFY-9262
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
Depends-On: #1827