fix(server): Grok no longer offers Auto-accept edits

[juliusmarminge]

Grok offered Auto-accept edits, but grok agent can't run it. At launch it takes only ask/default, its auto classifier, or always-approve. acceptEdits exists only as a settings-file permissions.defaultMode, and GROK_DEFAULT_PERMISSION_MODE accepts only auto/ask/default. Since #13616, T3 imitated the mode by launching Grok asking and approving edit prompts itself. The rule is that a provider doesn't offer a mode it can't run natively, and T3 doesn't imitate it.

What changed

• GrokProvider's presentation sets supportedRuntimeModes: ["approval-required", "auto", "full-access"], as PiProvider does. Web (ChatComposer) and mobile (thread-settings-options) already filter their pickers on this list.
• Server-side fallback. RuntimePolicyV2.resolve (the production layerFromProjectRepository) reads the thread's provider snapshot. A stored runtime mode the provider doesn't list runs in Supervised (approval-required). Without this, an older thread or a stale client would still send Auto-accept edits. Every turn start, restart, and session open resolves its policy here, so the fallback holds on all of those paths. Providers that list no modes are unchanged.
• grokAcpSpawnArgs has no Auto-accept edits branch anymore. Any mode Grok doesn't offer launches asking (--permission-mode default).
• Two V2 layer test fixtures (runtimeLayer.test.ts, DelegatedCompletionDelivery.test.ts) had a ProviderInstance with an empty snapshot. They now get a getSnapshot that lists no modes, since the resolver reads it.

Decisions (override if you disagree)

• The fallback is Supervised for every unsupported mode, not "the next stricter supported mode". For Grok the two are the same thing. Pi's list omits auto, and Pi already maps auto to approval-required in its launch env (piT3McpInjection.ts), so its behavior doesn't change. A per-mode ladder would only matter for a provider that offers Auto but not Auto-accept edits, and none does.
• AcpClientPolicy keeps its auto-accept-edits rule (approve edit/delete/move, ask for the rest). Grok no longer reaches it, but generic ACP Registry agents run Auto-accept edits through this rule. Without it they'd auto-approve commands in that mode, as they did before fix(server): V2 Grok launches in the thread's permission mode #13616. Only the Grok-specific wording in its comment changed.
• Docs are left to docs: ACP agents run their own tools, and Grok has no Auto-accept edits #13634, which rewrites "Provider differences" to say Grok offers no Auto-accept edits.

Verification

In apps/server, with TMPDIR under /home:

• GrokAdapterV2.test.ts > Grok launch permission mode > launches a thread stored as Auto-accept edits asking: builds Grok's real initial provider snapshot and resolves a thread stored as auto-accept-edits through the production RuntimePolicyV2 layer. It gets approval-required, and opening a session through the real Grok makeRuntime spawns --permission-mode default agent stdio.
• RuntimePolicy.test.ts > runs a mode the provider does not offer in Supervised: Grok's list maps auto-accept-edits to approval-required and keeps auto and full-access. A provider with no list keeps auto-accept-edits.
• Mutation: with the resolver ignoring supportedRuntimeModes and the spawn args mapping auto-accept-edits to always-approve, both tests fail.
• vp test run on RuntimePolicy, GrokAdapterV2, GrokAcpSupport, GrokProvider, AcpClientPolicy, runtimeLayer, DelegatedCompletionDelivery, AcpAdapterV2, AntigravityAdapterV2, AcpRegistryAdapterV2: 268 passed.
• OrchestratorReplayFixtures.integration.test.ts -t "grok|antigravity|acpRegistry": 21 passed. Every Grok fixture runs in Full access or with an explicit override, so none changed.
• vp exec tsc --noEmit -p .: no error TS or warning TS. vp run knip:check: clean. vp lint on the touched files: clean.
• Not run: live Grok, or a web/mobile UI pass. The picker filtering already exists and is unchanged.

Model: Claude Opus 5.5 (Claude Code)

🤖 Generated with Claude Code

---

[macroscopeapp]

Import this service module as a namespace at the new service boundary, then use ProviderInstanceRegistry.ProviderInstanceRegistry in the layer requirement and yield* acquisition. This preserves the module's public service shape.

^{Posted via Macroscope — Effect Service Conventions}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	4.9 KiB	—	6.8 KiB	✅
Codex	Thread snapshot wire	—	3.7 KiB	—	4.9 KiB	✅
Codex	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Codex	Live turn WebSocket decoded	—	20.4 KiB	—	29.3 KiB	✅
Codex	Live turn messages	—	2	—	8	✅
Claude	Total thread wire	—	4.9 KiB	—	6.8 KiB	✅
Claude	Thread snapshot wire	—	3.7 KiB	—	4.9 KiB	✅
Claude	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Claude	Live turn WebSocket decoded	—	20.8 KiB	—	29.3 KiB	✅
Claude	Live turn messages	—	2	—	8	✅

Baseline: unavailable · PR result: e2dba3e · 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: 106.1 KiB
• Claude decoded thread snapshot: 106.4 KiB

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