Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Summary
Keep open: current main still has a source-level token scope widening path, and the linked open fix PR #79206 uses closing syntax for this issue. The issue should stay open until that PR or an equivalent fix lands.

Reproducibility: yes. at source level: current main widens the approved baseline from existing plus pending scopes, while token minting returns the pending role-scoped list directly when scopes are present. I did not execute a live pairing flow in this read-only review.

Next step
No separate repair job: this issue is already paired with open closing PR #79206, so the next action is normal PR review and landing rather than a competing ClawSweeper branch.

Security
Needs attention: The issue reports a concrete authorization scope-widening problem in device pairing token minting, so the linked fix should receive security-focused review before landing.

Review details

Best possible solution:

Land #79206 or an equivalent narrow fix that keeps the approved baseline as the full union while minting role tokens from the existing token scopes plus only newly requested deltas, with regression tests and the existing changelog entry.

Do we have a high-confidence way to reproduce the issue?

Yes, at source level: current main widens the approved baseline from existing plus pending scopes, while token minting returns the pending role-scoped list directly when scopes are present. I did not execute a live pairing flow in this read-only review.

Is this the best way to solve the issue?

Yes, the linked PR direction is the narrow maintainable fix: preserve the separate approved baseline contract but compute newly minted token scopes from the current token plus the upgrade delta. The issue should remain open while that PR is reviewed and landed.

Security concerns:

[high] Prevent unintended operator scope regranting — src/infra/device-pairing.ts:440
A deliberately narrowed operator token can regain omitted scopes during an approved upgrade if token minting uses the widened approval set instead of the current token plus the requested delta. This matters because it can silently expand a device session's effective permissions.
Confidence: 0.83

What I checked:

current token minting path: On current main, resolveApprovedTokenScopes returns the pending role-scoped request directly when a pending approval includes scopes, so an upgrade request can determine the newly minted token scope list instead of starting from the current narrowed token. (src/infra/device-pairing.ts:440, 79e31421225b)
approved baseline is separately widened: approveDevicePairing still merges the existing approved baseline with the pending scopes, which is correct for the durable baseline but creates the distinction this bug is about: baseline widening should not silently rehydrate omitted token scopes. (src/infra/device-pairing.ts:600, 79e31421225b)
documented expected behavior: Pairing docs say an already paired device does not get broader access silently and that scope upgrades are explicit, which supports classifying this as a bug rather than a new feature. Public docs: docs/channels/pairing.md. (docs/channels/pairing.md:163, 79e31421225b)
linked closing PR: The open PR fix(pairing): preserve narrowed token scopes on upgrade #79206 is mergeable and says it changes token resolution to merge current token scopes with only the newly requested delta, with regression tests in src/infra/device-pairing.test.ts. (b6b746d820b5)
related active report: Search also found the broader open report [Bug]: CLI device pairing: scope upgrades trigger infinite request loop; token rotation drops prior scopes #78727 about scope-upgrade loops and token rotation dropping prior scopes, so this issue is part of an active pairing-scope cluster rather than stale cleanup.

Likely related people:

steipete: Recent GitHub commit history for src/infra/device-pairing.ts and docs/cli/devices.md shows multiple pairing/token containment changes, including device token scope containment and CLI device approval scope behavior; this account also authored the paired fix PR. (role: recent maintainer and security-adjacent pairing owner; confidence: high; commits: 8bbb143ab87e, b660493e5466, e8f13c625e34; files: src/infra/device-pairing.ts, src/infra/device-pairing.test.ts, docs/cli/devices.md)
pgondhi987: Commit history shows this account changed approveDevicePairing to validate caller scopes against resolved token scopes and introduced the staged nextTokenScopesByRole flow that is directly adjacent to the reported minting behavior. (role: adjacent approve-token-scope maintainer; confidence: medium; commits: 189c91eae6e1; files: src/infra/device-pairing.ts, src/infra/device-pairing.test.ts)
eleqtrizit: Recent history on the same pairing source and tests includes bootstrap handoff scope bounding, which is adjacent scope-contract work for device pairing tokens. (role: adjacent bootstrap scope hardening owner; confidence: low; commits: b8372a714ccc; files: src/infra/device-pairing.ts, src/infra/device-pairing.test.ts)

Remaining risk / open question:

This review did not run a live physical mobile/device pairing flow; the proof is from current-main source, docs, related issue context, and the linked PR patch.
The broader scope-upgrade loop in [Bug]: CLI device pairing: scope upgrades trigger infinite request loop; token rotation drops prior scopes #78727 may still contain additional CLI or lifecycle behavior beyond this narrow token-scope fix.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 79e31421225b.

Uh oh!

Pairing scope upgrades can widen narrowed role tokens #79246

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions