chore: merge upstream pingdotgg/t3code through 8d75232489

[andrewcai8]

The daily upstream sync is still stuck. #200 merged upstream through 12069eefd7 but failed Typecheck, and upstream has since moved 433 commits ahead. This branch builds on #200 and merges upstream 12069eefd7..8d75232489 by hand, as a real merge commit. The fork's cloud machines, Home, worker forks, account rotation and background-shell fixes all stay. Upstream wins everywhere the fork had not deliberately changed something. Merging this also lands #200, so #200 can be closed.

Notable upstream changes

• Providers and source control are packages now. Codex and Claude stay in the server. The rest move to packages/provider-* (core, acp, acp-registry, cursor, grok, muse, opencode, pi, testing) and packages/source-control-* (core, github, gitlab, bitbucket, azure-devops, forgejo, gitcafe). That accounts for 348 renames.
• Settings. The legacy per-driver providers map is gone (refactor(settings): drop the legacy per-driver providers map pingdotgg/t3code#17300). Providers can be turned on or off per project (feat(settings): providers can be turned on or off per project pingdotgg/t3code#17879), and built-in models can be renamed (feat(server): rename built-in models from settings pingdotgg/t3code#18840).
• Pull requests. Guided reviews (feat(pull-requests): guided reviews, a beta tour of a pull request pingdotgg/t3code#18124), MCP tools to write and read review guides (feat(mcp): agents can write and read pull request review guides pingdotgg/t3code#18143), quick actions that follow each host's capabilities (feat(pull-requests): quick actions follow each host's capabilities, not GitHub pingdotgg/t3code#17774), and native PR browsing and review on mobile (feat(mobile): browse and review pull requests natively pingdotgg/t3code#18126, feat(mobile): guided reviews for pull requests pingdotgg/t3code#18267, feat(android): add Pull Requests tab pingdotgg/t3code#18372).
• Other changes:
  • Open T3 Code from a link with a prompt ready (feat: open T3 Code from a link with a prompt ready to send pingdotgg/t3code#18454).
  • The draft screen's project picker is searchable (feat(web): draft screen project picker is searchable pingdotgg/t3code#17664).
  • Stop a Claude subagent without stopping its owner (feat(server): stop Claude subagents without stopping their owner pingdotgg/t3code#17826).
  • Antigravity quota and usage limits (feat(provider-antigravity): support subscription quota and usage limits pingdotgg/t3code#17530).
  • OpenTelemetry export settings in Diagnostics (feat(web): configure OpenTelemetry exports in diagnostics pingdotgg/t3code#12538).
  • T3 Code can be the default browser on macOS (feat(desktop): T3 Code can be your default web browser on macOS pingdotgg/t3code#17587).
  • 23 perf commits.

What the fork had to adapt

RPC group split. ws.ts hit "Type instantiation is excessively deep". Upstream's own ws.ts fails the same way once the fork's RPCs are added, so this is group size, not a cascade from other errors. packages/contracts/src/rpc.ts now builds CoreWsRpcGroup (upstream's list) and CloudWsRpcGroup (Home, fleet, environment control). WsRpcGroup is their merge, so clients see the same group. The fork's handlers move into layerCloudWsRpc in ws.ts. That leaves the fork's footprint in upstream's big handler map at the getConfig and updateSettings tweaks, which should make the next sync smaller.

settings.providers removal (pingdotgg#17300). A cloud box used to switch off every driver it was not given by leaving it out of the providers map. ProvisionPreparation now writes an explicit enabled: false default instance for each such driver. ProvisioningProviderProfile takes CursorSettings from @t3tools/provider-cursor/settings. The test helper that checks "no other driver on the box" now resolves implicitly enabled default instances. Before this, those tests passed even with the disabling code removed.

Fork code moved with upstream's packages:

• Cursor multi-login usage now lives in provider-cursor. CursorUsageAccounts.scan reads the host login plus each Cursor instance's own login. usage/cursorLogins.ts and provider/cursorCredentialPath.ts are deleted.
• cursorBillingCycle.ts moves into provider-cursor.
• providerCheckPermits.ts (the fork's limit on concurrent provider checks) moves into provider-core.
• The fork's CODEX_HOME rule sits on upstream's Effect-based mergeProviderInstanceEnvironment.

Fixes outside the conflicts:

• Home agents could see models the user hid. FleetService now passes providerModelPreferences to providerCapabilities, and the parameter is now required. A new FleetService test covers it.
• @t3tools/shared/hostProcess became HostProcess (refactor(shared): host process references live in a HostProcess module pingdotgg/t3code#17641) in five fork files.
• Fork MCP tests gain the layers upstream's new test setup no longer provides (notHomeLayer, ServerSettings.layerTest()).
• ScheduledCloudFire declares upstream's new ThreadManagementProviderInstanceDisabledError.
• The fork's useHandleNewThread.cloud.test.ts gets the resolveNewThreadEnvMode and readThreadShells stubs that upstream added to its sibling test.
• Three web call sites follow upstream signature changes. HomeSettings passes projectId and environmentId, and useCloudChat imports ATTACHMENT_ONLY_BOOTSTRAP_PROMPT from shared.
• Mobile cloud-machine status labels gain the icons that upstream's StatusLabel now requires: Retrying arrow.clockwise, Waking sun.max, Updating arrow.down.circle, Asleep moon. These icons are a judgment call. Swap them freely.

Verification

• Independent review: PASS+NOTES on 0fb872b1c0 (chore: merge upstream pingdotgg/t3code through 8d75232489 #202 (comment)). It ran a real cloud RPC through the split group, with authorization and instrumentation.
• Typecheck reports 0 errors in apps/server, apps/web, apps/mobile, apps/desktop, packages/contracts, packages/client-runtime, packages/shared, packages/provider-core and packages/provider-cursor. Before this, the server had 154 errors after the merge.
• Server. src/home, src/mcp, src/environmentControl, src/usage, src/provider, src/scheduledTasks, src/auth, ws.test.ts and serverSettings.test.ts: 182 files, 2390 of 2395 tests pass. The 5 failures come from the machine I ran on, which is itself a cloud chat box:
  • Four pass with a clean environment (env -i). They had read the host's real AWS key and its cloud-machine prompt note.
  • The fifth, E2bProvisionRuntime guardMemoryCommand, finds the host's real /usr/bin/earlyoom through the test's PATH. Upstream did not touch environmentControl in this range.
• Orchestration. The adapter, thread, turn-start, session manager, background-work-after-limit and DiskHeadroom tests: 10 files, 616 tests pass.
• Packages. provider-core: 22 files, 194 tests pass. provider-cursor: 16 files, 117 tests pass.
• Web. src/cloud, src/hooks, src/components/settings, src/components/chat, src/components/usage, composerDraftStore and state/shell: 198 files, 2274 tests pass.
• Mobile. src/features/threads and the outbox drain: 46 files, 406 tests pass.
• vp fmt --check passes on every changed file. vp lint on the 181 hand-resolved files has no errors. Its warnings are ones upstream's versions already have.
• vp i installs the fork's extra dependencies (e2b, @namespacelabs/sdk, connectrpc, undici) on top of upstream's lockfile.

Tests must run with the repo's local node_modules/.bin/vp (1.0.0, matching CI). An older global vp (0.3.0) fails every test that imports @effect/vitest at load, with "Cannot read properties of undefined (reading 'config')".

Risks

• No test sends a cloud RPC such as fleet.connect over a real socket after the group split. The evidence is the 0-error typecheck: RpcServer.make on the merged group does not compile if any handler is missing from the two merged layers.
• Unverified guess: a box still running a build from before refactor(settings): drop the legacy per-driver providers map pingdotgg/t3code#17300 reads the providers map, which the host no longer writes, so its unused drivers would stay on. Boxes on this build get the explicit disabled instances.
• Home and remote launches through FleetService still skip upstream's worktree base-ref check (feat(server): every T3 MCP tool declares who may call it pingdotgg/t3code#16335). This was already true before this merge, and Home is full-access only. They do get the new per-project provider check (feat(settings): providers can be turned on or off per project pingdotgg/t3code#17879), because FleetService launches through ThreadLaunchService.launch.
• Low, inferred from the code (independent review): in ClaudeAdapterV2.ts the fork's processEnded flag is read before upstream's new per-message replay. A CLI that exits during replay is not seen by that continuation. The fork's test for a CLI dying mid-wake still passes.

Claude Opus 5.5 (1M context), Claude Code

🤖 Generated with Claude Code

[andrewcai8]

Independent verification: PASS+NOTES (verified head 0fb872b; its code is 8f87b63 plus a one-line test fix in ForkMigrations.test.ts)

I did not write this code. I looked for fork or upstream behavior the merge lost, and checked the RPC group split at runtime.

Method

• I diffed both sides from the true merge base 12069ee. Then I used a script to check whether every non-trivial line each side added still appears at HEAD. That covered the 160 files both sides changed, plus the 37 files only one side changed that the merge still adapted. Every missing line was then read by hand.
• I listed files the fork changed that no longer exist at HEAD (11). For the 6 that moved into packages/provider-*, I checked that the fork's lines survive at the new path.
• Fork RPC membership: the union of the fork's 192 and upstream's 193 group entries equals HEAD's 201. Nothing was dropped and nothing new appeared.

Findings

1. No fork behavior lost. Every fork line missing at HEAD was moved, re-expressed, or replaced on purpose:

   • refuseLocalRun in sendToThread is covered by dispatch, which runs it first (ThreadManagementService.ts:657).
   • environmentControlWsHandlers moved into layerCloudWsRpc (ws.ts:3187).
   • The CODEX_HOME rule sits on the Effect-based merge (codexProviderEnvironment.ts).
   • Hidden-model filtering moved into the shared providerCapabilities.
   • Cursor multi-login moved into CursorUsageAccounts.scan with the same rules. It skips the host's own login, skips a Keychain login that is turned off, and dedupes by source dir.
   • ProvisionPreparation still disables every driver that was not provisioned. The provisioned driver's default instance is overwritten by its account, because guestInstanceId equals defaultInstanceIdForDriver. So a re-provision cannot leave a stale enabled:false.

2. No upstream behavior lost.

   • thread/tools.ts is the only file where the fork side won outright. Upstream's one change there (initialAnswer) was ported to FleetRequestReadResult (contracts/src/home.ts:250).
   • Upstream's reworked readThread (multi-task acknowledgement) is intact. readThreadPage matches upstream's inline page logic.
   • Upstream's thread_send description is kept, with the fork's Home sentence appended.

3. The RPC split routes cloud RPCs correctly, proven at runtime. In Effect, Rpc.key is effect/rpc/Rpc/${_tag} and ignores middleware. RpcServer finds handlers by that key and applies middleware from the group passed to make, which is ServerWsRpcGroup (both middlewares on every RPC). I wrote a throwaway test, now deleted, using:

   • the real WsRpcGroup.middleware(RpcInstrumentation);
   • handlers from two separate Core…/Cloud…ServerWsRpcGroup.toLayer layers;
   • the real RpcAuthorization.layer and rpcInstrumentationLayer.

   Results: home.disable reached the cloud handler and server.probe reached the core handler. A read-only connection got EnvironmentAuthorizationError (missing orchestration:operate) and the handler never ran. The ws.rpc.home.disable span and the t3_rpc_requests_total{method=home.disable} counter were recorded both times. RpcTest and RpcServer.make share makeNoSerialization, so only the socket and serialization layer went untested, and the split does not touch it.

4. Migration 61 reasoning is confirmed. moveForkLedger matches fork rows by name (forkIds/droppedForkMigrations), not id. A fork-era [61, "ProvisionedChats"] row is deleted and re-inserted as fork id 4 before runUpstream runs. So upstream's migrator resumes at ≤60 and applies 61 PullRequestReviewGuides. Migrations.ts:153 lists it and the manifest goes to withForkMigrations (:272). On 8f87b63, CI's only test failure was this file. I ran the 0fb872b version and all 5 tests pass.

Notes (none block landing)

• Low: Claude wake-buffer merge (ClaudeAdapterV2.ts, continuation replay). The fork's processEnded is read from the buffer snapshot taken before upstream's new per-frame replay. A CLI exit during replay is not seen by that continuation. A frame requeued during replay also keeps processEnded: true through { ...buffered, messages }. That is inferred from the code; no test exercises it. The fork's test "settles a wake continuation whose CLI died before the wake turn's result" passes.
• Correction to the PR's Risks section: Home launches do get upstream's per-project provider check. FleetService calls ThreadLaunchService.launch, which calls assertProviderInstanceEnabled (ThreadLaunchService.ts:784). The worktree base-ref skip is still true and predates this merge.
• CI on 0fb872b was still running when I posted this. Lint, Typecheck, Build and Test Server 5 were green.

What I ran (local node_modules/.bin/vp, server tests under env -i … CI=true)

• Server: ClaudeAdapterV2.test.ts, ClaudeBackgroundWorkAfterLimit.test.ts, ProvisionPreparation.test.ts, FleetService.test.ts, CodexAdapterV2.codexHome.test.ts, UsageService.cursorLogins.test.ts (324 tests). Then ThreadLaunchService.test.ts, OrchestratorMcpService.test.ts, RpcAuthorization*.test.ts, RpcInstrumentation.test.ts, cloudReach.test.ts (127 tests). Also ForkMigrations.test.ts at 0fb872b (5 tests). All passed.
• Packages: provider-cursor/src/server (117 tests) and provider-core managedProvider.permits.test.ts. All passed.
• The throwaway cloud-RPC routing test above passed and was deleted. The working tree is clean.

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ The exact PR base did not have a successful artifact. Baseline uses the latest successful main measurement shown below.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	5.0 KiB	4.9 KiB	−23 B (−0.5%)	6.8 KiB	✅
Codex	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.2 KiB	1.2 KiB	−23 B (−1.9%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	20.9 KiB	20.8 KiB	−41 B (−0.2%)	29.3 KiB	✅
Codex	Live turn messages	2	1	−1 (−50.0%)	8	✅
Claude	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Claude	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	21.2 KiB	21.2 KiB	0 B (0.0%)	29.3 KiB	✅
Claude	Live turn messages	2	2	0 (0.0%)	8	✅

Baseline: 57fde0d · PR result: 0fb872b · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.