fix: request issue, agent tool, and page OAuth scopes

[justinhelmer]

Summary

Request the seven issue, agent tool, and page scopes exposed by current CLI commands during browser and device OAuth login.

Root cause

The CLI's static login scope list was not updated when these permission families were added in July. The production "Polylane CLI" OAuth client also omitted them. A fresh login on CLI 0.2.28 or 0.2.45 therefore cannot grant issues:read, even to a workspace admin. GET /v1/scopes lists available scopes, not a token's grants.

The reported MCP API key is a separate credential. Its key ID and grant history still need validation before customer handoff.

Verification

• npm run typecheck, npm run lint, npm run test (537 passing), npm run build, and git diff --check passed locally on this two-file change. CI runs Node 20/22/24 on the rebased head.
• Production "Polylane CLI" OAuth client oauth_client_db0e300c0001s66dhw481fxn was updated and read back: all seven new scopes are allowed. The nine retired wikis, automations, and skills scopes were removed because the current client API rejects them. Every scope in this PR's login request is allowed by the live client.
• A local build of this two-file change completed a fresh production device login in an isolated profile. The granted token contained all 64 requested scopes, including issues:read, and polylane issue list --limit 1 succeeded against production. An existing CLI session also refreshed successfully after the client update. The temporary test tokens were revoked.
• Live device authorization accepted the current published 0.2.45 scope request and rejected 0.2.28's request. Users on CLI versions before 0.2.35 may need to upgrade before signing in again because those versions request retired scopes. Existing signed-in sessions continue to refresh.

Release follow-through

After human merge, cut and verify the new CLI release and installer. Then confirm a fresh login and issue listing with the released build, inspect the customer's MCP API key grants or have them replace an old installer key, and only then send the customer handoff.

[coreplane-switchboard]

Changes requested: The new default scope request depends on a production OAuth client allowlist update that the PR says is still outstanding.

Warning

Changes requested · head 157b18a · 1 finding: 1 major

Severity	Finding	Where
major	F1 Update the production OAuth client allowlist before requesting these scopes	src/auth/oauth.ts:41

Full review

F1 (major, high confidence): The PR states that the production “Polylane CLI” OAuth client does not yet allow these seven scopes, but both browser and device login now request them unconditionally. Until the allowlist is updated, a fresh login may fail with invalid_scope or receive a token that still cannot list issues. Confirm the production allowlist change and a fresh-login polylane issue list replay before shipping.

[coreplane-switchboard]

Plan runner — U1 waiting for a person

⏸️ Waiting for a person after 1 review round: #119 — every finding of review round 1 is human-gated, a receipt only a person can produce: F1 (major) — Update the production OAuth client allowlist before requesting these scopes. The unit stays live; no unanswered fix round was opened.

Severity addressed: minor and above (set by org).

The next reply in this unit thread or authorized pull request comment becomes the fix round's answer; review then runs again.

[justinhelmer]

F1 is addressed. I updated and read back the production "Polylane CLI" OAuth client: it now allows all seven scopes added by this PR, and its allowlist exactly matches the PR's 64-scope login request. The current client API rejected nine retired wikis, automations, and skills scopes, so I removed those from the client allowlist; the PR body now records the compatibility effect for CLI versions before 0.2.35.

I built this exact PR head with the production client in an isolated local profile, completed a fresh production device login, confirmed the token includes issues:read, and ran polylane issue list --limit 1 successfully. I also refreshed an existing CLI session after the client update. The PR body contains the full verification and remaining release/MCP follow-through. Please re-review the current head.

[coreplane-switchboard]

LGTM: The seven scopes are requested by both login flows, and the production allowlist and fresh device-login issue-list replay address F1.

Note

Approved · head b92d2a3 · no findings

Full review

F1 is resolved by the documented production allowlist update and fresh device-login issue-list replay. No remaining findings at b92d2a3.

[github-actions]

Auto-approved: coreplane-switchboard[bot] reviewed this PR and posted an LGTM verdict (see its review). A repo admin enabled this via the auto-approve workflow.