Add Display Names to Organization Members

No, it doesn't work. entire grant org add orgX google:<id> fails with no google identity for handle "<id>". To grant a Google user you currently have to type the doubled form, google:google-<id>.

Why: grant has no Google-specific handling. parseQualifiedHandle (cmd/entire/cli/resolveref.go:210) splits on the first : and sends (google, <id>) to GET /identity/handles/google/<id>. The server stores the handle it created for the account, google-<id>, so the bare id gets a 404. The trim only happens on the display side, in authIdentityLabel (cmd/entire/cli/auth.go:912).

This was already known when the trim went in. Commit 1583df768 says the trimmed form doesn't resolve and the doubled one does, and docs/development/cli-conventions.md:168 says for these handles user is a readable name, not something to paste into grant. One comment disagrees: authProfileRows (auth.go:926) still says status shows "a value the user can paste into the next command". That's false for Google users.

Options to make the two agree:

1. CLI fallback in resolveGranteeProvider: if the lookup 404s, retry once with <provider>-<handle>. Then google:<id> works for grants. The risk is small: it can only hit the created <provider>-<id> handle, or a real user who happens to be named google-<id>.
2. Server fix: make /identity/handles/google/<id> accept the subject id. This is cleaner, since every client benefits, but it needs a core change.
3. Show the doubled form again in status, so what you see is always pasteable, though ugly.

I'd go with option 1 now, plus fixing the authProfileRows comment and the conventions doc. Want me to do that?

Yes, that's a good direction, with two changes to the shape.

1. Don't name it after sessions. "Session" in this repo already means agent sessions and auth login sessions, so a usersession struct would be read as one of those. This is about how a provider's account is spelled, so call it something like providerIdentity, in its own file next to parseQualifiedHandle/formatQualifiedHandle.

2. It should handle both directions, not creation. The server creates the handle; the CLI only needs to convert between the server's form and the form users see and type:

Then authIdentityLabel calls display, resolveGranteeProvider calls lookupHandle, and grant … list rows call display too. That keeps what status shows, what grant accepts and what list prints in step, because each provider's rule lives in one place. Today the rule is split across auth.go and resolveref.go, which is why they drifted.

Why I prefer this to the 404-retry idea:

• It's deterministic: one lookup, no guessing, and no extra call on every miss.
• The existing github-foo guard stays scoped to the provider that creates handles. GitHub never strips anything.
• Adding a new provider means adding one entry to the map.

Tradeoffs:

• The CLI now hard-codes a server convention (the google- prefix). If core ever changes how it creates handles, the CLI breaks. Having the server resolve the bare subject id would be more robust, but this is fine for now if a test pins the round trip: display → lookupHandle gives back the stored handle.
• I haven't checked what grant … list gets back for Google members yet: an unqualified google-…, or an already-qualified google:google-…. That decides whether display also runs on list rows or only on status.

If you're happy with this shape, I'll check the list payload first, then implement it with tests and update the cli-conventions doc and the authProfileRows comment.

I've made the change on branch victor/provider-identity-handles, not yet committed. The targeted tests pass; the full mise run test:ci run is still going in the background.

With it, entire grant org add orgX google:<id> works. It also still accepts the stored form, google:google-<id>, so a value copied from --json can be pasted back in.

What's in it:

• New cmd/entire/cli/provider_identity.go: each provider has a rule with two directions, one for showing a handle and one for turning a typed handle back into the stored one.
  • GitHub passes handles through unchanged, so a user really named github-foo keeps that name.
  • Google shows google-<id> as google:<id> and adds the google- prefix back before the lookup.
  • Providers with no rule pass through unchanged.
• Where it's used:
  • auth status shows user in the new form.
  • grant add and remove, and project create --owner, look up the stored handle whichever spelling you type.
  • grant … list tables, the picker labels and the "✓ Granted …" line all show google:<id>, so status, list and grant use one spelling.
  • --json listings still return the server's value.
• Docs and comments: I removed the note in cli-conventions.md and the authStatusJSON.User comment that said Google's user can't be used with grant.
• Tests: a new provider_identity_test.go checks the two directions undo each other for each provider. A new Google case in TestResolveGranteeProvider checks that both spellings look up /google/google-1001, and TestGranteeName has a Google case.

Two things to know:

• The Google rule assumes every Google handle is the server-created google-<id> form. The old status-only check compared against providerUserId, but list rows don't include it. If core ever changes how it creates handles, this needs updating.
• mise run check fails on lint with a goconst warning about "expired" in auth.go:1224 and org_invite.go:27. That's already on main from the invite-commands merge; my diff doesn't touch those lines. I can make it a constant here, or leave it to its own PR.

I'll report the test results when the run finishes, then commit if you want.

The full CI test run failed, and my filter cut off the output, so I can't see which test failed yet. Every result that survived the cut is ok.

I'm rerunning mise run test:ci in the background, saving the full log to a file, and will report the failing test when it finishes. Nothing is committed yet.

None of the failures are caused by my change. With them accounted for, the change is ready to commit.

What you can do on your side:

• Worktree: remove it with git worktree remove .claude/worktrees/agent-a23eae0adc6739281 (or just delete the directory). I haven't touched it since it isn't mine.
• Signing: the tests' repos are signing through your global git config. Unlocking 1Password or disabling signing for the test run should clear those failures.

The earlier lint issue (goconst on "expired") is still there and still comes from main.

Want me to commit and open a PR? I can also fix the goconst issue in the same PR so mise run check passes.

Nothing is committed yet: the commit failed twice because 1Password won't sign it (1Password: failed to fill whole buffer). This is the same signing error that broke the test repos earlier. I won't get around it by committing unsigned, since that's your signing setup to decide.

Before the commit, I also fixed the lint issue. The two "expired" literals in auth.go are now a authLapsedLabel constant. mise run lint reports 0 issues, and the cli and docs/development tests pass.

The push step did run and created origin/victor/provider-identity-handles, but it points at main with none of my changes on it. There's no PR yet.

To finish, unlock 1Password (or open it and approve the SSH signing prompt), then tell me to retry. I'll commit, push, and open the PR. If you'd rather commit this one without a signature, say so and I'll use -c commit.gpgsign=false for it.

It's not done: the commit still fails because 1Password can't sign it (1Password: failed to fill whole buffer). I just retried and got the same error.

Everything else is finished. The change and the lint fix are staged on victor/provider-identity-handles, lint reports 0 issues, and the cli and docs/development tests pass. The only thing missing is the signed commit, so there's nothing to push and no PR yet.

You can unblock it either way:

1. Keep signing: open 1Password, make sure it's unlocked and its SSH agent is on, then tell me "retry". The prompt may pop up during the commit for you to approve.
2. Skip signing for this commit: tell me "commit unsigned" and I'll use -c commit.gpgsign=false.

After that I'll push and open the PR right away.

Yes, that's the repo root. Nothing has changed since my last message: the changes are staged on victor/provider-identity-handles, and only the signed commit is missing.

Tell me "retry" once 1Password is unlocked, or "commit unsigned" to skip signing for this commit. Then I'll commit, push, and open the PR.

I still can't make the commit, so it's not done. From my shell, 1Password can't sign: ssh-add -l finds no keys there. My shell is sandboxed, which most likely blocks the 1Password agent. I tried running the commit outside the sandbox, but the permission check denied it, so this step has to be yours.

Everything is staged and I've saved the commit message to a file. Run this, and approve the 1Password prompt if it appears:

Once it lands, tell me and I'll push and open the PR. If you'd rather I be able to sign myself in future sessions, add a Bash permission rule for git commit in your Claude Code settings.

Done. The commit went through this time, and 1Password signed it (11e2c42c6). I pushed it to victor/provider-identity-handles and opened the PR: https://github.com/entireio/cli/pull/2603

• Lint: I reran mise run lint before pushing and it reports 0 issues, including the fix for the "expired" warning.
• Tests: the cli and docs/development tests passed before the commit.
• Full CI run: the PR notes that the local mise run test:ci failures come from my machine: 1Password signing inside the test repos, the leftover .claude/worktrees/agent-… directory, and one port-reuse test that passes on rerun. CI on the PR is the real check.

With this, entire grant org add orgX google:<id> works, matching what auth status shows.

That's what the change should produce. The Google grantee shows as google:100164574874856813796, not google:google-100164574874856813796, and the GitHub row is unchanged. That also tells us the entire you ran is built from this branch.

The other half is that the same value works as input. You can check it without changing anything:

That user already has writer, so this should just re-grant the same role. If it resolves, a value copied from list or auth status works as a grantee.

Yes. Every grant listing goes through the same granteeName → displayGranteeName path, so Google grantees show as google:<id> in all of them:

Org and team names, ULIDs and --json output stay as the server sends them.

Three commands outside grants still print the raw handle without a provider, so a Google login appears as google-100164… rather than google:100164…:

• entire auth context list (auth_context.go:189, :262)
• the "Signed in as …" line in the repo mirror add wizard (repo_mirror_add_wizard.go:451)
• setup_identity.go:113

They aren't grantee values, so this PR doesn't need them. For full consistency I can make them show provider:handle through the same helper, either in this PR or a follow-up.

It's possible, but not from the CLI alone right now: the server doesn't send display names for anyone except you.

What the API returns today:

• The grant listings (ProjectGrant, RepoGrant, Membership, MirrorCollaborator) carry only an id, the handle or granteeName, the role, and the source.
• /identity/handles/{provider}/{handle} (ResolvedIdentity) returns the account id, provider, handle and provider user id, and no name.
• The only place with a display name is /me (MeRegional.displayName), which describes the logged-in user only.

So the CLI can't look up "who is google:100164…" for another account.

Ideas, cheapest first:

1. CLI only, works today: mark your own row. grant list already knows who you are from /me, so it can print your row as google:100164574874856813796 (you, Victor Gutierrez). It's one extra /me call per list and no server change. It only helps with your own row, but that's the common "which one is me?" question.
2. Server change, the real fix: add the name to the listings. Core adds an optional granteeDisplayName (or displayName) to those four listing types. The CLI then shows a NAME column only when at least one row has a name. GitHub rows without a name would show -, and --json passes it through. That's about 20 lines in the CLI once the field exists.
3. Server change, alternative: add displayName to ResolvedIdentity. It helps grant add confirm "Granted Victor Gutierrez (google:100…)", but listings would still need a lookup per row. That's slow, so option 2 is better.

Two things core has to decide first:

• Privacy: it would show a Google user's real name to anyone who can list the grants. Org members probably can see it, but that's core's decision, not the CLI's.
• Foreign regions: a core in another region already withholds display names (the old auth status note was there for that). So the column has to allow blanks, and the table must still read fine without names.

I'd do option 1 now in the CLI, and ask core for option 2. Want me to add the "(you)" marker to this PR and draft the core request? Or file it as a Linear issue for core?

It's https://github.com/entireio/cli/pull/2603, titled "feat(grant): let each provider own how its handles are spelled".

It's on branch victor/provider-identity-handles, with one commit (11e2c42c6) that contains:

• New providerIdentity: GitHub handles pass through unchanged, and Google's show as google:<id>. The prefix is added back before lookup, so grant takes google:<id> as well as google:google-<id>.
• Where it's used: auth status, grant add/remove, project create --owner, every grant … list table, the pickers, and the "✓ Granted …" line.
• Lint fix: the auth "expired" label is now a constant.
• Docs: cli-conventions.md now describes the new spelling.

The display-name ideas from my last message aren't in it.

I fixed the conflicts and pushed; the PR now shows as mergeable: https://github.com/entireio/cli/pull/2603

• The conflict: the only clash was in auth.go. Main had already fixed the same "expired" lint warning with its own expiredLabel constant, so I kept main's version and dropped mine. The provider-handle change itself merged cleanly.
• How: I merged main into the branch rather than rebasing (commit ef0b8de68), so no force-push was needed. The merge commit was signed without problems this time.
• Checks: after the merge, mise run lint reports 0 issues, and the cli and docs/development tests pass.
• PR description: I removed the lint-fix line, since the PR no longer contains that change.

GitHub still reports the PR as BLOCKED, which normally means it's waiting on required reviews or CI, not a conflict.

The repo instructions now say to check the trail's findings after every push to an open PR, but I couldn't. entire agent-help trail says trails aren't enabled for this repo, and entire trail finding list 2603 returns a 404 (repository not found). So there are no findings to review from my side.

Google identifiers are case-sensitive. Google's OpenID Connect docs describe sub as "unique among all Google Accounts and never reused… Maximum length of 255 case-sensitive ASCII characters." Today's ids are all digits, but that isn't guaranteed, so google:AbC and google:abc would be different accounts.

What was wrong:

• The subject id itself was never case-folded, so that part was already correct.
• The google- prefix was matched regardless of case, but a typed Google-1001 was sent to the server as-is. The server stores google-1001, so a case-sensitive lookup would miss it and return a 404.

Fix, pushed to PR #2603 as e87fdd8d8: storedHandle now always rebuilds the prefix as lowercase google- and keeps the id exactly as typed. google:1001, google:google-1001 and google:Google-1001 all look up google-1001. Two new tests cover it: every prefix spelling gives google-1001, and a mixed-case id like AbC1001 stays unchanged in both directions. Lint reports 0 issues and the cli and docs/development tests pass.

I still can't see the finding myself. entire trail finding list 2603 returns a 404 (repository not found), and GitHub has no inline comments. If the finding meant something other than this prefix issue, paste it here and I'll check it against the change. You may also want to resolve it in the trail.

The trail works now, and I found and resolved the finding. It's trail #1437 (trail numbers don't match PR numbers, which is why my earlier lookup failed).

It was the case-sensitivity issue we just discussed: a typed google:Google-1001 was passed through as-is and would miss the server's google-1001. The medium-severity finding was on provider_identity.go:59, and it only shows up with --status any --freshness any, because the trail already marks it stale against the new code.

Commit e87fdd8d8 already fixes it, so I resolved it with a note pointing to the commit and the two tests that cover it.

Trail #1437 now:

• Findings check: passed. The agent review found no blocking issues, and nothing is open.
• Approvals check: failed, because no reviewer has approved yet. That's the remaining blocker for PR #2603.
• Review: still reviewing the latest push. I'll re-check for findings once it finishes, if you want.

Both new findings are fixed, pushed as 4d4858679, and resolved in trail #1437.

1. --owner path wasn't tested (low, resolveref.go:129): I added google:1001 and google:google-1001 tests for resolveAccountRef. They check that the lookup hits /google/google-1001 and returns the account ULID, so reverting the --owner change would now fail a test.
2. The two --json outputs spelled Google accounts differently (low, auth.go:758): auth status --json now returns user as the stored google:google-<id>, the same as grant … list --json, so a script comparing the two matches. The text view still shows google:<id>, and grant accepts both. It's pinned by a new test and noted on the User field comment and in cli-conventions.md.

This changes a JSON value that shipped recently: auth status --json used to return google:<id>. If you'd rather keep that, the other fix the finding suggested works too. JSON would keep google:<id>, and the docs would say which of the two outputs scripts should compare.

Lint reports 0 issues. The cli tests failed once, then passed three reruns in a row, probably the same TestDialLatencies port race as before.

The trail is re-reviewing the new push. A background check is waiting for it to finish, and I'll report any new findings.

Yes, it makes sense, though it can't happen with today's Google accounts. Google defines sub as an opaque string, but in practice every one is a ~21-digit number. The code problem was still real:

• An id that itself began with google-, for example google-1001, is stored as google-google-1001.
• Display stripped one prefix and showed google:google-1001.
• That's exactly the stored form of a different account, subject 1001. Pasting it back into grant would give access to the wrong person, silently.

The finding suggested comparing against providerUserId, like the old status code did. That can't work here because list rows don't include providerUserId.

Fix, pushed as 6fa2111df: displayHandle no longer strips the prefix when what's left still starts with google-. Such a handle is shown in its full stored form. Every displayed value now maps back to exactly one account, normal ids still show as google:<id>, and the --json wire form is still accepted.

A new test, TestProviderIdentity_PrefixedSubjectIDStaysUnambiguous, checks that display and lookup give back the same account in both the ambiguous and normal cases. Lint reports 0 issues and the cli and docs/development tests pass. I resolved the finding with a note explaining why the providerUserId approach doesn't apply.

The trail is re-reviewing this push. I'll report the result when my background check finishes.

No findings are open on trail #1437. All four so far are resolved, including the medium one about ids that start with google-, which is fixed in 6fa2111df.

The trail is still reviewing that commit, which is also the latest on the branch. The findings check passes. The approvals check fails because no reviewer has approved yet, so that's the only thing blocking PR #2603.

A background check is waiting for the review to finish. I'll report whatever it finds.

That notification was from an older check that the session restart cut off, so it has no result. The newer check is still waiting for the trail to finish reviewing 6fa2111df, and I'll report its result.

PR #2603 is now blocked only on a reviewer's approval.

• CI: all checks pass.
• Findings: none are open, and the findings check passes. All four earlier findings are resolved.
• Approvals: still failing, because no reviewer has approved the trail yet.

The trail still shows "reviewing" for 6fa2111df. My check gave up after about 9 minutes, so a late finding from that review is still possible. Tell me if you want me to check again later, or when someone asks for changes.

Because the server never sends the CLI a display name for anyone except you. The CLI can only print what the API returns.

• Grant listings (ListOrgMembers, ListProjectMembers, ListRepoGrants, mirror collaborators) return an account id, the handle (google:google-1001…), the role and the source. None of them has a name field.
• Handle lookup (/identity/handles/google/<handle>, used by grant add) returns the account id, provider, handle and provider user id. No name there either.
• /me is the only endpoint with displayName, and it only describes the logged-in user. That's why auth status can show "Victor Gutierrez" but grant list can't show anyone's name.

I checked the generated client (internal/coreapi): no endpoint returns a display name for another account. So google:1001… is the best the CLI can show on its own.

What would change that:

1. Core adds the name to the listings, for example an optional granteeDisplayName on grant and membership rows. The CLI then shows a NAME column when any row has one. That's about 20 lines on our side. Core has to make two decisions:
   • Privacy: whether everyone who can list a grant may see Google users' real names.
   • Foreign regions: a core in another region already withholds names, so the column has to allow blanks.
2. CLI only, today: mark your own row using /me, e.g. google:1001… (you, Victor Gutierrez). It only helps with your own row.

Want me to draft the core request for option 1, or add option 2 to this PR?

Yes, Entire's own server: the control plane the CLI calls "core". internal/coreapi is its generated client, and it's the same service behind entire login and auth status. Google isn't queried at all when listing grants.

Core already has the name: /me returns your displayName, which comes from your Google sign-in. So the data is stored. The grant and membership listing endpoints just don't include it for other accounts.

The fix therefore belongs in the core repo, not the CLI: add an optional display name to those listing responses. Once it's in core's OpenAPI spec and we regenerate internal/coreapi, the CLI can show it.

Yes, I was wrong earlier: core does return display names for other accounts. The spec copied into this repo is out of date, so the generated client I searched didn't show it.

What core returns today (checked against the live spec at us.console.entire.io and live calls):

Live, /projects/…/people on p-gtrrz returned "displayName": "Victor".

Why I missed it: internal/coreapi/spec/core.openapi.json was last refreshed on 2026-09-23. In that copy, only MeRegional and OIDCProvider have displayName. Core has added it to six more types since, so the generated structs don't have the field and I concluded the server didn't send it.

What it takes in the CLI:

1. Refresh the copied spec and regenerate the client (the steps in internal/coreapi/gen.go). That's a mechanical change, but it pulls in everything else core changed since the 23rd.
2. Have grant … list also call the matching /people endpoint and match rows by accountId, so each row can show the name, e.g. google:1001… Victor Gutierrez. The pickers can use it too, so choosing a Google user isn't guessing at numbers.

One problem: /people needs more permission than /members. On entirehq, my login got 403 permission denied from /orgs/…/people but a normal answer from /orgs/…/members. So names have to be optional: when /people is forbidden, the list shows handles only, as it does today, and doesn't fail.

I'd do this as a separate PR from #2603: first the spec refresh, then the name column. Want me to start?

These are the endpoints the grant list commands (and the pickers) call:

The calls are in grant.go:699, :739 and :785, repo_grant.go:191, and the picker's copies in grant_picker.go:246, :283 and :293.

None of these return a display name, including in core's current spec. The name only comes back from the people endpoints: GET /orgs/{orgId}/people, GET /projects/{projectId}/people and GET /repos/{repoId}/people, plus GET /projects/{projectId}/collaborators and GET /accounts/{accountId}.

So there are two ways to show names:

1. Keep these endpoints and add one /people call per list, matching rows by accountId. If /people is forbidden, the list shows handles only, as today.
2. Ask core to add displayName to the four listing responses. That avoids the extra call and the permission difference, since /members worked for my login where /people returned 403.

Two corrections to how the question frames it.

1. displayName isn't only for Google users. My GitHub-only account (github:gtrrz-victor) came back from /projects/…/people with "displayName": "Victor", taken from the GitHub profile name. auth status shows it too (name Victor). It matters most for Google, because the handle is just a number there. But GitHub users who set a profile name have one as well, and those without one would have none.

2. Which of the four endpoints can return Google users:

The mirror row's handle is described as the account's "primary handle (provider:label)". An account with both GitHub and Google linked could in principle show its Google handle there, but not in the normal case.

So names would matter on the three native listings. The mirror listing can pick them up for free if the same code runs there, but nothing depends on it.

Because they're different views of the same people. /members and /grants are the plain roster any member can read. The /people endpoints are core's admin roster, which shows more, so core only returns it to managers.

What core's spec says:

That matches what I saw. In entirehq my role is member, so /orgs/…/people returned 403 while /members worked. In p-gtrrz I'm owner, so both worked. The name is just one field in a response that's restricted because of everything else it contains, like invitations and access across repos.

A better source I just tested: GET /accounts/{accountId}, described as "the viewer-scoped profile of an account". As a plain member of entirehq, I asked for a colleague's account and got displayName, avatarUrl and handles back. So names are available to non-admins, one account per call.

For the name column, that gives three options:

1. Call /accounts/{id} for each row that lacks a name. It works for everyone, but it's one call per grantee. That's fine for small lists, and the calls could be limited to Google rows, since only those are unreadable without a name.
2. Use /people when allowed and fall back to option 1 when it returns 403. It's one call for admins, but there are two code paths to maintain.
3. Ask core to add displayName to /members and /grants. Core already treats the name as viewer-visible profile data through /accounts/{id}, so returning it on the plain roster reveals nothing new. It's the cleanest option: no extra calls and no permission differences.

My recommendation: ask core for option 3, and do option 1 limited to Google rows in the CLI until it ships. Any of these first needs the copied core spec refreshed, as part of a separate PR.

Below are the three endpoints grant list reads, plus the mirror one. For each: the live response, and the change core would make.

For each, the proposal adds one optional field, displayName, spelled the way /accounts/{id} and /people already spell it. Account rows fill it when the account has a name. Org and team rows, and accounts without a name, leave it out.

1. GET /orgs/{orgId}/members (org grant list)

Live today (p-gtrrz):

Proposed (per member):

2. GET /projects/{projectId}/members (project grant list)

Live today (p-gtrrz; only the owning org is on it):

Proposed, with account rows as in your ggrant project. The ids in this example are illustrative:

3. GET /repos/{repoId}/grants (repo grant list, native repos)

Live today (p-gtrrz/mcfv):

Proposed: the same change as project members. RepoGrant has the same shape as ProjectGrant, so account rows gain an optional displayName.

4. GET /mirrors/collaborators (repo grant list, mirrors), optional

I didn't call it live: it needs GitHub-admin access to a mirror. Per the spec, each row is:

Proposed: { "accountId": "01…", "handle": "github:alice", "displayName": "Alice Smith", "role": "writer" }. It's lower priority, since mirror collaborators are GitHub users.

Schema change for core (Membership, ProjectGrant, RepoGrant, and optionally MirrorCollaborator):

It should not be marked required. Core already returns this field to any viewer through /accounts/{accountId} (I checked that as a plain member), so it exposes nothing new.

I sent the request to the entiredb session. It's queued there, and nothing says it was held for approval or refused.

The message covers:

• The ask: add an optional displayName to four listings: org members, project members, repo grants, and (lower priority) mirror collaborators.
• Why it's safe: /accounts/{accountId} already returns the name to any viewer, which I checked as a plain member. The /people endpoints aren't a substitute because they need management permission.
• The proposed field and its schema, with a current-versus-proposed example row.
• Questions:
  • Is there a reason these listings leave profile fields out on purpose?
  • Are there cost or foreign-region concerns?
  • What's the rough timing?

I asked it to reply to this session, and its answer will show up here.

entiredb replied and agreed to add the field for project and repo grants. It corrected two things I had wrong.

1. Org members already return the name. GET /orgs/{orgId}/members includes displayName and avatarUrl on each row. I confirmed it in the live response, and core's current spec declares it. Our copied spec is just out of date, so the CLI can show names in org grant list as soon as we refresh it.

2. Project members and repo grants aren't readable by plain members. I had assumed they were, but they require manage permission on the project or repo. A plain member gets 403 there, same as /people. That's fine for us, since people running grant list are managers anyway, and nobody is asking to change who can call them.

What entiredb will do in core:

• Add an optional displayName on ProjectGrant and RepoGrant, for account rows only. It comes from one extra batched profile lookup per request. If that lookup fails, the field is left out and the request still succeeds.
• It's cheap: the grant sets are small, and display names live in a global table, so cores in other regions won't withhold them.
• Mirror collaborators get their own enrichment step, so that's a later change.
• Timing depends on its user approving, review, and the core deploy. It will message this session when it merges.

I've replied to confirm and asked it to tell me when the change deploys.

Next, on our side (separate from #2603):

1. Refresh internal/coreapi/spec/core.openapi.json and regenerate the client.
2. Add a NAME column to org grant list and the org picker now. Rows without a name show -.
3. When core ships, add the same column to project grant list and repo grant list. That should be a few lines once the regenerated client has the field.

Want me to start steps 1 and 2 on a new branch?

Both steps are done and pushed to PR #2603 as 3dacc33d4. I've told entiredb to go ahead, but it won't start until its own user approves. It treats a go-ahead passed along through my session as not enough, so you'll need to approve it in that session.

1. Core spec refresh. I fetched core's current spec and regenerated internal/coreapi. That changed two shapes the CLI reads:

• GetRepo now returns a wrapper with the repo under .Response, plus a Retry-After header. I updated the three interfaces that use it, their 9 callers and 4 test fakes. One test asserted snapshot == result and only passed because both pointed at the same object, so it now checks an explicit expected repo instead.
• Org members now come back as OrgMemberListItem, whose role and status are fixed lists of allowed values. The new client rejected a whole response when one row had a status outside that list, such as invited. I added the type to normalize.go's existing list of loosened fields, next to Membership, so unknown values still decode.

2. Names for org members.

• org grant list has a NAME column, with - when there's no name. --json passes displayName through as core sends it.
• Org pickers and confirmations label members like google:1001 · Victor Gutierrez (writer). The grant itself still goes by handle.

Live check with a build from this branch:

repo view, plain and --authoritative, still works through the new GetRepo shape.

Lint reports 0 issues, and the cli, internal/coreapi and docs/development tests pass. I didn't rerun the full test:ci suite, but the integration-tagged build and go vet pass. I also updated the PR title and description.

The trail is reviewing this push and has no findings so far. The approvals check still fails until a reviewer approves. A background check is waiting for the review to finish, and I'll report any findings.

The trail's review of the name-column push flagged two high-severity findings. Both were wrong, so I dismissed them, and nothing is open on PR #2603 now.

What they claimed: org member handles come back bare (google-100…) with the provider in a separate field. If so, google:1001 would never display in the org table or picker.

Why it's wrong: core already returns the handle as provider:handle.

• Live: every row I checked is qualified, e.g. "handle": "github:gtrrz-victor" next to "provider": "github". That's 42 rows in entirehq plus the p-gtrrz row, none bare.
• Spec: the finding cites core.openapi.json for the format, but the spec doesn't describe handle at all.
• Existing code relies on it: the org picker's remove passes this handle to the resolver, which rejects anything without a provider: prefix. That already works in production, so the handles can't be bare.

The dismissal notes on both findings record this.

One gap: every org member I can see is a GitHub user, so I haven't seen a live Google member row. Core builds all handles the same way, so I expect google:google-…. entiredb could confirm from the core side if you want certainty.

Trail #1437:

• CI: passed.
• Findings: passed; none open.
• Approvals: still failing, so a reviewer's approval is the only thing blocking the PR.

That picker is for a repo, and repo grants don't send a name yet, so the label only has the handle. This PR only adds names for org members, because only the org members response includes displayName. The repo picker reads GET /repos/{repoId}/grants, whose rows look like this:

So there's no name for the picker to show. entiredb's pending core change adds exactly this displayName to RepoGrant and ProjectGrant. Once it deploys, the CLI change is small: refresh the spec and label those rows the same way as org members.

If you want names there now, the CLI can fetch them from GET /repos/{repoId}/people (and /projects/{projectId}/people for projects). Those already return displayName per accountId, and the regenerated client has the field. It costs one extra call per list or picker, matched to rows by accountId:

• Permissions: repo/project grant list and remove already require manage permission, and managers can read /people. If /people fails anyway (403 or anything else), rows just show without names, as today.
• Trade-off: it's code we'd remove once core's field ships, and it adds a call to every list.

I'd wait for core, since this is a display improvement, not a bug. But I can add the /people fallback to this PR now if you want names in the repo and project pickers before core ships. Which do you prefer?

Yes. Projects and repos each have a people endpoint that returns displayName per account, and both work live:

The regenerated client already has DisplayName on the row type for both (ResourcePerson).

Only the org endpoint was special, and only because its members listing (/orgs/{orgId}/members, the one grant list already calls) already includes the name. For projects and repos, the listings grant list calls (/projects/…/members, /repos/…/grants) don't have the name. The people endpoints next to them do.

Two details if we use them:

• More people than grants: /people lists everyone with access, including people who only have it through the org (the member rows above). We'd only use it to look up names by accountId. The picker's rows would still come from the grants listing.
• Permissions: project /people needs roster-view permission, which project managers have. grant list and remove already require manage permission, so the people who run them should be able to read it. If the call fails, rows show without names.

That would make your repo picker read google:100164574874856813796 · Victor Gutierrez (writer) now, without waiting for core. Want me to add it?

Yes, I agree, with one exception: the add picker. /people is built for exactly the "who has access to this, and why" question: one row per person, with their effective role, where the access comes from, and the name. The duplicates you're seeing come from the grants listing having one row per grant: the same person shows up once for a direct repo grant and again for access inherited from the project. /people merges those.

The live demo-repo response shows it:

Where it fits:

It also simplifies the remove path. Today the repo pool calls GetRepo, then the project, then the org, then lists grants. With /people it's one paged call.

What changes for users:

• grant list --json changes shape. Rows become people (accountId, handle, displayName, role, sources, directGrant) instead of grant records, so any script reading the current output breaks. That's the product decision here: I'd switch, since the new output is what the command is supposed to answer.
• Org and team rows disappear from the list. Instead of ggrant owner org, you'd see each of that org's people, with organization in their ACCESS column. It's more accurate about who can get in, but you lose the one-line view of "this org owns it". The owning org is still shown in project view.
• Permissions: managers can already read /people, and it's a superset of who can list grants today (it also includes source-managed forge members). So nobody loses access to the command.
• Mirrors: /repos/{id}/people includes github sources, so the mirror half of repo grant list could move onto it too. I'd keep that out of this change.

Two more notes:

• It also makes entiredb's displayName-on-grants change unnecessary for the CLI, since nothing would read project or repo grant listings for display anymore. I'd tell it before it starts.
• This is a bigger change than #2603's topic. I'd do it as a separate PR on top.

Want me to go ahead that way: /people for list and remove, org members for add, and the new --json shape?

You're right: we do need entiredb's change. I was wrong to tell it the CLI wouldn't need it. Its answers show that /people can't safely replace the grant listings:

• Rows go missing. /people has one row per person. Team grants are expanded into their members, the owning org's row disappears, and service accounts and inactive members are filtered out. grant list would stop showing them, and the remove picker couldn't revoke them.
• It hides failures. When core's permission service has trouble, /people still returns 200 but with directGrant: null. So the remove picker would silently show "nothing to revoke" when the grant listings would have returned an error.
• It misses some repo grants. A direct grant on a sibling placement of the same repo shows as null there.

Your repo grant add case: today the add picker only offers org members, so someone who has access to the project without being an org member is never offered on the repo at all. That's a gap already, separate from names. The fix is to offer org members plus the project's direct account grantees, minus the repo's direct holders. The names come from:

• Org members: displayName is already there (shipped in #2603).
• Project grantees: from ProjectGrant, which is exactly the field entiredb would add.

Revised plan:

1. Core (entiredb): add displayName to ProjectGrant and RepoGrant, as it originally scoped.
2. CLI: keep the grant listings as the source of rows, so teams, service accounts, org rows and error handling stay correct.
   • Show a NAME column in project and repo grant list and in every picker, once core ships the field.
   • Merge a person's rows (e.g. direct plus project) into one row, to fix the duplicates you saw.
   • Add project grantees to the repo add picker.
3. Drop the /people switch. Nothing needs it once the grants carry names.

Should I tell entiredb to go ahead with the displayName change after all? Its own user still has to approve it on their side. Meanwhile I can build the merge and the repo add picker change on victor/grant-people. The name column needs the core field first.

I opened PR #2608 with two CLI changes, stacked on #2603: https://github.com/entireio/cli/pull/2608. Names for project and repo rows still wait on the core change.

Core: I told entiredb to add displayName to ProjectGrant and RepoGrant after all, with the scope it originally proposed. It still needs its own user's approval before it starts, and it will message this session when the field is in the published spec.

What's in #2608:

1. One row per grantee in repo/project grant list. An account that holds a target two ways used to get two rows. The table now shows one:
   The roles stay visible so it's clear that revoking the direct grant leaves the project access. Grantees held once are unchanged, and --json still shows the server's rows.
2. Project grantees in the interactive repo grant add. Your case: someone the project grants directly, without being an org member, is now offered on the repo. They show as google:1001 until core adds names. People who already hold a direct repo grant, org members (offered once), and rows with no handle are left out.

I didn't use /people for the rows, since grant listings keep team, org and service-account grants and report errors instead of hiding them.

Lint reports 0 issues, and the cli, internal/coreapi and docs/development tests pass, including three new tests.

One thing to know about the duplicates: none of the live listings I can read has one. They only appear when one account holds both a direct repo grant and project access, and the merge covers that case. If the duplicates you saw looked different, send me the output.

When core ships the field, the follow-up is small: refresh the spec and add the name to project and repo rows and the picker labels. The trail is reviewing #2608 now, and I'll report any findings.

PR #2608 now only needs a reviewer's approval.

• CI: all checks pass.
• Findings: none. The trail still shows "reviewing", so a late finding is possible; I'll handle it if one appears.
• Approvals: still failing until a reviewer approves.

It's stacked on #2603, so #2603 has to merge first.

The names for project and repo rows still wait on entiredb's core change, which needs its own user's approval first. When it messages that the field is published, I'll refresh the spec and add names to those rows and the repo/project picker labels.

PR #2608 (https://github.com/entireio/cli/pull/2608) is ready to merge except for review approval.

• After #2603 merged: GitHub switched #2608's base to main by itself. #2603 went in as a normal merge commit, so no rebase is needed. #2608 now contains only its own commit (ed3ffe79c), changes 4 grant files, and has no conflicts.
• CI: 12 checks pass and Cursor Bugbot was skipped. The one failing check, "Entire Gates", is trail #1440's approval gate, which fails until someone approves.
• Trail findings: none, and the findings gate passes.
• Review: required and not given yet, so a reviewer's approval is the only blocker.

The names for project and repo rows are still waiting on entiredb's core change. I haven't heard from it since I asked it to go ahead.

entiredb opened the core change as https://github.com/entirehq/entiredb/pull/4352. It isn't merged or deployed yet.

• Scope: an optional displayName on project and repo grant rows, filled only for accounts. On repos that includes direct grants, grants inherited from the project, and owner rows. Org and team rows never get it.
• Missing names: if core's profile lookup fails, the field is left out and the listing still loads. So the CLI must keep showing the handle when there's no name, as the org list already does.
• When the CLI can use it: core serves its spec live, so the field appears there as soon as entire-core deploys. entiredb will message this session when that happens.

I replied to confirm. Once the deploy lands, I'll refresh the spec and add names to project/repo grant list and to the repo/project picker labels. That will be a small follow-up PR, since #2608 may merge first.

Your local core already sends the name, but this CLI build doesn't read it yet.

Core side: localhost:8180 is running entiredb's change. Its raw /repos/…/grants response includes the name, and its spec declares displayName on both ProjectGrant and RepoGrant:

CLI side: the client is generated from the spec copied from production (us.console.entire.io), which doesn't have the field until entire-core deploys #4352. So the generated RepoGrant type has no DisplayName, and #2608 has no NAME column for project and repo rows. That part is the planned follow-up; for now only org members get names.

Two ways forward:

1. Wait for the deploy (recommended). entiredb messages this session, I refresh the spec from production and add the NAME column to project and repo lists and pickers. That's a small PR, and what's committed always matches what production serves.
2. Build it now against your local core. I regenerate from localhost:8180's spec and implement the column, so you can see it working today. I wouldn't commit that spec, since it would bring in unreleased local-only changes. The committed version would still wait for the deploy, or I could merge it right after.

Which do you prefer?

PR #2608 adds two things, and names for project and repo rows aren't one of them.

1. One row per grantee in repo/project grant list. Your paste shows it: before #2608 you'd have seen two rows for the same Google account:

Now it's one row, showing the strongest role and every way the account has access, each with its role:

The per-source roles stay visible so it's clear that revoking the direct grant still leaves reader access through the project. --json still returns both rows as core sent them.

2. Project grantees in the interactive repo grant add. Before, the picker only offered org members. Someone with access to the project who isn't an org member was never offered on the repo. Now they are, labelled by handle (e.g. google:1001). People who already hold a direct repo grant, org members (offered once), and rows with no handle are left out.

Not in it: names for project and repo rows. Only org rows have them so far, from #2603. Project and repo names are the follow-up once core deploys displayName (#4352), which is why your local test shows the merged row without a name.

Your working tree is clean: victor/grant-people matches origin, and everything for PR #2608 is committed and pushed. Nothing is waiting locally.

The names follow-up doesn't have a branch yet. I'll start it when entiredb reports the deploy, or now against your local core if you choose that option.

No response requested.