Repository navigation
[Bug]: iOS Provider accounts fails with missing providers:manage on fresh T3 Connect tokens #16804
Description
Observation
On T3 Code Nightly 0.0.46-nightly.20261007.2761 (Windows x64 environment), the iOS client 2.0.0 opens Provider accounts but both Cursor provider panels fail with:
The authenticated token is missing required scope: providers:manage.
The server trace independently records provider.auth.subscribe failing with:
EnvironmentAuthorizationError: The authenticated token is missing required scope: providers:manage.
A freshly issued mobile DPoP session at 2026-10-07T11:02:46.233Z has exactly:
- orchestration:read
- orchestration:operate
- terminal:operate
- relay:read
It does not have providers:manage. Several fresh mobile sessions show the same restricted scope set, so this is not just an expired token. This report concerns mobile T3 authorization, independently of the provider's own credentials.
Why it matters
The authenticated mobile client exposes account management UI, but subscribing to its provider auth state fails before any provider login can begin. User cannot reconnect a provider through the displayed account panel.
Where to investigate
Verified against the installed server bundle, whose source regions identify:
apps/server/src/auth/RpcAuthorization.ts:RPC_REQUIRED_SCOPES,rpcAuthorizationError,requiredScopesForRpcCallrequire providers:manage for provider auth RPCs, including subscribe.packages/contracts/src/auth.ts:AuthStandardClientScopesincludes providers:manage;authScopeRequiredResponsesupplies compatibility response fields.apps/server/src/auth/EnvironmentAuth.ts: token exchange intersects requested scopes with granted scopes.apps/server/src/cloud/CloudLink.ts: managed-connect pairing creation uses AuthStandardClientScopes.- The iOS/managed-connect token-exchange request should be checked for an outdated requested scope set. The exact component omitting the permission has not been established.
Expected state and acceptance
- A client authorized for provider management requests and receives providers:manage, and Provider accounts can subscribe/start the supported login flow.
- A deliberately restricted client remains restricted, but UI explicitly reflects the missing permission instead of showing a broken sign-in panel.
- No blanket permission widening or disabling server scope checks.
- Cover old/narrow mobile scope requests and full permitted scope requests across token exchange and provider auth subscription.
Evidence (2026-10-07)
Local sanitized report: P:\codex-memory-palace\palace\projects\t3-multinode-env\provider-diagnosis-2026-10-07.json; companion diagnosis .md.
Server evidence: ~/.t3/userdata/logs/server.trace.ndjson.1, span ws.rpc.provider.auth.subscribe; metadata-only read of auth_sessions in ~/.t3/userdata/statev2.sqlite.
No credential values, tokens, account identifiers, IP addresses, or secret store contents are included.
Activity
juliusmarminge commentedon Oct 7, 2026
Note
Grok responding on behalf of Julius.
Thanks for the detailed report. I can confirm this is a bug. Server permissions changed, and released mobile clients weren't carried over.
Root cause
orchestration:operateto the newproviders:managescope.provider.auth.subscribe, start, complete, respond, cancel and logout now all require it (apps/server/src/auth/RpcAuthorization.ts:62-72).CloudLinkmints the pairing grant withAuthStandardClientScopes(apps/server/src/cloud/CloudLink.ts:1620), and that list includesproviders:manage(packages/contracts/src/auth.ts:205-219).apps/server/src/auth/EnvironmentAuth.ts:901-904). The session you saw has exactlyorchestration:read,orchestration:operate,terminal:operateandrelay:read. That is the overlap between the standard grant and the frozen pre-granular wire vocabulary (legacyScopes,packages/contracts/src/auth.ts:130-140). So the iOS 2.0.0 build is asking for the old scope list, and nothing on the server translates it into the new granular scopes. Currentmainmobile/client-runtime code sends noscope(packages/client-runtime/src/authorization/service.ts:340-345) and would receive the full grant.providers:manage(apps/mobile/src/features/settings/SettingsEnvironmentDetailRouteScreen.tsx:84), but a client built before that check still shows the panel. That's why you get a broken sign-in panel instead of a hidden or disabled one.Proposed fix (no blanket widening)
orchestration:operateto the scopes it covered before feat(auth): separate environment administration permissions #9786 (providers:manage,settings:write,environment:maintain). Still keep only what the bootstrap grant allows. Explicit granular requests stay unchanged.provider.auth.subscribe.permissions, and show a "missing permission" state instead of the sign-in panel.Workaround
For now, use desktop or web to sign in to providers. Once an iOS build that no longer sends the old scope list ships, remove and re-add the environment to get a fresh session.
juliusmarminge commentedon Oct 7, 2026
Note
Grok responding on behalf of Julius.
#16856 reports the same four-scope session from the macOS desktop app on server
0.0.46-nightly.20261007.2774, paired with a fresh link that had all 16 permissions. There it shows up as the Files panel saying "This connection cannot read host files", becausefilesystem:readis dropped too. So the compatibility fix here should cover the desktop app as well, and the legacy expansion needs to include every scope split out of the old vocabulary (includingfilesystem:read), not only the provider-management ones.entity commentedon Oct 7, 2026
Same issue here on iOS 2.0.0 against
0.0.46-nightly.20261007.2761(Linux server). The clone flow fails withmissing required scope: source-control:writeand the folder browser withfilesystem:read. The pairing link had 13 scopes and the storedauth_sessionsrow had only the four legacy ones, sosource-control:writeis affected as well.Two things that might matter for the fix:
verifySessionTokenreturnsclaims.scopesfrom the signed token, butverifyWebSocketTokenreturnsrow.value.scopesfromauth_sessions. Any migration would need to account for both.Workaround that worked for me: I updated the iPhone session's
scopesinauth_sessionsto match its pairing link's grant (no server restart), then force-quit and reopened the iOS app. After that the folder browser and cloning a repo both worked. Bearer HTTP requests presumably still carry the token's original four scopes until a new token is issued, so some HTTP-only paths may still fail.theophanemayaud commentedon Oct 8, 2026
Same issue here with the Files screen on an iPhone.
0.0.46-nightly.20261007.2761.Opening Files shows:
A fresh mobile session issued 2026-10-08 at 04:08:37 UTC, after the host update, still has only these scopes in
auth_sessions:So this also blocks file browsing, and updating the host does not resolve it for build 110. No session permissions were manually modified.
Is there a fixed TestFlight build available, or a supported way to refresh the permissions for this client?
AISupplyGuy commentedon Oct 8, 2026
Same here on TestFlight 2.0.0 (110) against 0.0.46-nightly.20261008.2801 on two Linux servers and two macOS hosts. It isn't limited to T3 Connect: pairing directly over Tailscale with a link that grants all 16 scopes also stores a 4-scope iOS session (
orchestration:read orchestration:operate terminal:operate relay:read). Clone fails withsource-control:writeand the folder browser withfilesystem:read. Desktop and Safari sessions on the same links get the full grant.theophanemayaud commentedon Oct 8, 2026
Another affected action on the same iOS TestFlight 2.0.0 (build 110): updating the host remotely is blocked by a missing
environment:maintainscope.The environment is shown as Connected, with T3 Connect in use. The host is on 0.0.46-nightly.20261008.2801, and the app offers 0.0.46-nightly.20261008.2813, but attempting the update shows:
This is in addition to the
filesystem:readfailure reported above. It also prevents using the iOS app to install the available host update, so I’m updating the Mac locally.treyecollins commentedon Oct 8, 2026
Another symptom of the same four-scope iOS session: media embedded in chat messages by host path never loads, and the UI doesn't say why.
auth_sessions(issued 2026-10-08T12:01Z) has["orchestration:read","orchestration:operate","terminal:operate","relay:read"].When the agent embeds a host file in its reply (
or a PNG path), the phone shows a bare Video unavailable / Image unavailable box. The host trace showsws.rpc.assets.createUrlfailing with:So the client never gets an asset URL. No
/api/assets/...request for those files reaches the server. Uploaded attachments (pasted images) in the same threads load fine with HTTP 200, because they don't needfilesystem:read. The Files screen fails the same way but at least shows the scope error. The chat embeds hide it behind a generic "unavailable", which made this look like an encoding or iOS player problem at first.Suggestion for the fix: when
assets.createUrlis refused for a missing scope, the media placeholder should say so ("This connection can't read host files") instead of "unavailable".jlipworth commentedon Oct 8, 2026
Another symptom of the same four-scope iOS session: Usage shows $0.00 on every environment.
cloud-connectsession issued today has["orchestration:read","orchestration:operate","terminal:operate","relay:read"]. Desktop sessions minted the same way in the same hour have the full standard set.server.getUsageSummaryandserver.refreshUsageRatesrequirediagnostics:read(apps/server/src/auth/RpcAuthorization.ts:106-107). Before that they only neededorchestration:read.This matters for the proposed fix.
diagnostics:readwas split fromorchestration:read, notorchestration:operate(legacyParents,packages/contracts/src/auth.ts:154-164). So expanding onlyorchestration:operateleaves Usage broken, the same gap noted above forfilesystem:read. Expanding a legacy-only request by everylegacyParentsentry whose parent was requested, then intersecting with the grant, would cover all the split permissions in one rule. It would also match whatsessionGrantsScopealready does on the client side for old servers.max-miller1204 commentedon Oct 8, 2026
Confirmed another fresh mobile 2.0.0 session with the same four-scope grant on 2026-10-08. This also shows that the pairing link had the missing permissions before redemption.
Read-only metadata checks in the macOS host's
statev2.sqlitefound:2026-10-08T14:32:34.948Z.2026-10-08T14:33:09.773Z.2026-10-08T14:33:09.776Z, withclient_app_version = 2.0.0.The consumed link's
auth_pairing_links.scopescontained 16 permissions:The resulting session's
auth_sessions.scopescontained only four:Two other fresh mobile 2.0.0 sessions on the same host had the same four permissions. The permission drop is stored in the session record, so it is not only a display problem. The consumed link explicitly granted
providers:manage, along with the other missing permissions.Reproduction observed:
Expected: mobile requests the permissions needed for its supported features, within the owner's grant. If it intentionally requests fewer permissions, the UI explains that restriction.
The environment auth documentation states that token exchange intersects requested scopes with the pairing grant. This matches the legacy scope request described in the maintainer response above. The token-exchange request was not captured in this reproduction, so this local evidence confirms the grant reduction rather than independently proving the request payload.
No credential values, pairing URLs, session IDs, device names, or account identifiers are included.