chore: merge upstream pingdotgg/t3code through 8ac4b97dae

[andrewcai8]

Main was 7 upstream commits behind after #202. This merges upstream 8d75232489..8ac4b97dae as a real merge commit. Git merged it without conflicts.

Upstream changes

• Snoozed threads accept queued automatic wakes, and Stop cancels buffered provider wakes instead of holding them (fix(server): snoozed threads allow queued automatic wakes pingdotgg/t3code#19099).
• Pi queues turn-start prompts while native work runs (fix(pi): queue turn-start prompts when native work is running pingdotgg/t3code#18639), and loads T3 tool schemas for completion gateways (fix(pi): load T3 tool schemas for completion gateways pingdotgg/t3code#18643).
• Agent tool startup failures on devices are reported (fix(devices): report agent tool startup failures pingdotgg/t3code#18502).
• Settings warn when an environment silently drops a setting (fix(web): settings warn when an environment silently drops a setting pingdotgg/t3code#18334).
• Cmd+Enter creates the new project while an option is highlighted (fix(web): Cmd+Enter creates the new project while an option is highlighted pingdotgg/t3code#18901).
• The PR merge button fits its label (fix(web): merge button fits its label and animates width changes pingdotgg/t3code#18478).

Overlap with the fork

Three files changed on both sides. All merged cleanly.

• Orchestrator.ts. Upstream changed snooze and Stop. Account switching (ProviderAccountSwitch) releases the session and continues, never issuing Stop. The fork's queue.hold is used only when Home stops a former Home thread. Neither reaches upstream's new Stop code.

Known issue from upstream

Independent review (#203 (comment)) found that after Stop cancels a queued Claude wake (pingdotgg#19099), the Claude adapter is not told. That chat then stops waking for later background work until its provider session is released. The bug reproduces with upstream's own adapter, so it is on upstream main too. It is a follow-up, not a blocker for this sync.

• runtimeLayer.test.ts. Each side added tests.
• CommandPalette.tsx. Each side changed different parts.

Verification

• Typecheck reports 0 errors in apps/server, apps/web and packages/provider-pi.
• Server. runtimeLayer, Orchestrator*, NotificationMailbox, ClaudeBackgroundWorkAfterLimit, ProviderAccountSwitch, src/device and ThreadSettlementService: 18 files, 211 tests pass.
• Web. CommandPalette, components/settings and components/pullRequest: 82 files, 1121 tests pass.
• provider-pi. 8 files, 140 tests pass.
• vp i leaves pnpm-lock.yaml unchanged.

Claude Opus 5.5 (1M context), Claude Code

🤖 Generated with Claude Code

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	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	0 B (0.0%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	20.9 KiB	20.9 KiB	0 B (0.0%)	29.3 KiB	✅
Codex	Live turn messages	2	2	0 (0.0%)	8	✅
Claude	Total thread wire	5.0 KiB	5.0 KiB	+24 B (+0.5%)	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	+24 B (+2.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	21.2 KiB	21.2 KiB	+41 B (+0.2%)	29.3 KiB	✅
Claude	Live turn messages	1	2	+1 (+100.0%)	8	✅

Baseline: 4e27301 · PR result: 72a3a95 · 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.

[andrewcai8]

Independent verification: PASS+NOTES (verified head 72a3a95)

The merge is a faithful union. git diff 4e27301176 HEAD has the same patch-id as upstream's 8d75232489..8ac4b97dae, and git diff 8ac4b97dae HEAD has the same patch-id as the fork's side. No hunk from either side was dropped or altered. The account-switch and usage-limit flows are unaffected. One upstream semantic change does retire a fork behavior and widens a latent stuck-wake bug. That bug exists on upstream main too, so blocking this sync would not remove it.

Findings

1. Medium, follow-up. After Stop cancels a queued Claude wake, the chat stops waking for later background work.

• Upstream fix(server): snoozed threads allow queued automatic wakes pingdotgg/t3code#19099 makes Stop cancel buffered provider wakes, held or not (apps/server/src/orchestration-v2/Orchestrator.ts:8878, ahead of the queueHeld skip at :8891). Claude continuations always qualify. ProviderContinuationService.ts:213-229 sets notification, createdBy: "agent" and creationSource: "provider".
• queued-run.cancel emits only run, attempt and node updates. Nothing tells the adapter.
• ClaudeAdapterV2.ts:6404 offers one continuation per native thread until requestedContinuations clears. Only a continuation drain (:8669) or clearWakeStateForNativeThread (:4041) clears it. Interrupting an active turn (:8809) does neither.
• Probe (measured). I copied the fork's "delivers a buffered wake after Stop ends the user turn queued ahead of it" scenario. I skipped the continuation, as the orchestrator now does, then ran a second backgrounded task to completion on a new user turn. With the continuation drained, the second task produced a continuation request (2 of 2). With it cancelled, it produced none (1 of 2), so the chat never wakes. I got the same result with upstream's ClaudeAdapterV2.ts from 8ac4b97 swapped in, so this is upstream's bug. The stale state lasts until the provider session is released, the live process is replaced for another native thread, or a Stop arrives with no active turn (:8762-8790).
• How to trigger it: press Stop on a running turn while a Claude background wake is queued behind it. The fork's ClaudeAdapterV2 test covers this race.

2. Low, note. Fork #193's "Stop no longer loses a queued wake" is superseded. On fork main, Stop held the wake, and resuming it replayed the buffer the adapter kept (processEnded). Upstream now cancels that wake on purpose. ClaudeAdapterV2.test.ts:6469 still passes, but it drives the adapter directly. The orchestrator no longer reaches that path through Stop. Session release (account switch) still uses processEnded.

3. Not an issue. Account switch and limit flows. ProviderAccountSwitch.ts:247 releases the session and dispatches a message.dispatch continuation. It never issues Stop or queue.hold, and environmentControl/accountSwitch.ts dispatches no orchestration commands. Release also discards the adapter's session state, which clears finding 1's stale state. In the limit flow, the banner's Stop reaches a settled turn. That takes the restart branch, which already cleared the wake buffer on fork main, so cancelling the wake loses nothing new. ProviderRuntimeRecoveryService runs only at startup and shutdown, when the buffer is gone anyway.

4. Not an issue. Other readers of queued runs. queue.hold is used by HomeService.stopFormerHome (home/HomeService.ts:192), followed by run.interrupt without holdQueue, so holdStoppedThread does not run. Home reports are createdBy: "system", so they are not buffered notifications. The fork's snooze readers (wakeAhead.ts:38, FleetService.ts:124/410) only read or dispatch snooze. A snoozed cloud chat with a queued automatic wake is now possible, and wake-ahead skips it. The box is busy while that wake waits, so I found no impact.

5. Not an issue. CommandPalette.tsx and runtimeLayer.test.ts. The fork's hunks (Home entry, Home-project filtering, new-chat placement) and upstream's hunks (Cmd+Enter create, around :3137 and :3238) do not overlap. Each side only added tests to runtimeLayer.test.ts.

PR body nit. It says queue.hold is used for account switch. It is used by Home's former-thread stop.

What I ran

• Patch-id equivalence for both merge sides.
• vp test run (server, env -i ... CI=true), all passing:
  • ThreadStop, ClaudeBackgroundWorkAfterLimit, ProviderAccountSwitch and src/home: 6 files, 47 tests.
  • runtimeLayer, ProjectionRecovery and ProviderRuntimeRecoveryService: 3 files, 102 tests.
  • ClaudeAdapterV2 -t wake: 201 tests.
• The finding 1 probe was a throwaway copy under /tmp. I ran it against the merged adapter and against upstream's adapter.
• CI is green on 72a3a95.

Suggested follow-up (not blocking)

Clear the Claude adapter's wake buffer and requestedContinuations for a native thread when Stop interrupts its active turn, or when the orchestrator cancels its buffered wake. Worth sending upstream, since pingdotgg#19099 introduced the cancel.