docs: ACP agents run their own tools, and Grok has no Auto-accept edits

[juliusmarminge]

The ACP Registry guide said T3 mediates agent file and terminal requests at the client boundary. That stopped being true: registry agents run their own tools (#13623), the generic client fs guard is gone (#13633), and only Devin's commands run through T3's terminals. The permission-modes page also didn't say that Grok offers no Auto-accept edits (#13719).

Rewritten to match what landed after the spec-only reshape. There's no per-agent mode mapping, and the agent's own mode picker stays visible (#13724, which replaces #13629).

What changed

• docs/user/providers-acp.md "Permissions and terminals" now explains:
  • Agents run their own tools under their own sandbox and approval rules, starting in their own default mode. Their mode picker switches that mode.
  • T3 Code answers an agent's approval request by the thread's permission mode, and the section spells out what each mode does. File reads and searches never wait.
  • Devin's commands run in T3 Code's terminals and follow the permission mode. For other agents, T3 Code shows the terminal output they report.
• docs/user/permission-modes.md "Provider differences" says Grok offers no Auto-accept edits, and that a Grok thread already set to it runs in Supervised. It also links to the ACP section for registry agents.
• "Models and options" is unchanged: registry agents still show their approval-mode setting.
• The rules in AGENTS.md's documentation section are followed: user voice, no implementation details. No internal doc described the removed client-boundary guard.

Verification

• vp fmt on both files. I checked each claim against the code: acpPermissionDisposition in AcpClientPolicy.ts for how each mode answers, AcpRegistryAdapterV2 for Devin's client terminals and for client fs being off, GrokProvider plus RuntimePolicy in fix(server): Grok no longer offers Auto-accept edits #13719 for Grok's modes and the Supervised fallback.
• The Grok sentence depends on fix(server): Grok no longer offers Auto-accept edits #13719. Merge that first.

Model: Claude Opus 5.5 (Claude Code)

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — The PR only revises two Markdown guides to document already-landed ACP and Grok permission behavior, with no executable or product-default changes. A separate unresolved High-severity ACP runtime-policy finding remains outside this documentation diff and should be handled by the repository's blocking correctness process.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[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.7 KiB	—	29.3 KiB	✅
Claude	Live turn messages	—	1	—	8	✅

Baseline: unavailable · PR result: 635dd11 · 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.

Dismissing prior approval to re-evaluate f0ffbb4

Dismissing prior approval to re-evaluate e4d4675

[macroscopeapp]

🟠 High Adapters/AcpAdapterV2.ts:1948

A restarted ACP runtime uses the original openSession policy instead of the later turn's policy, so a session opened in full-access remains in full-access after restarting for an approval-required turn. makeRuntimeInput should pass latestRuntimePolicy so launch-time permission enforcement matches the active turn.

Suggested change

	runtimePolicy: input.runtimePolicy,
	runtimePolicy: latestRuntimePolicy,

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/orchestration-v2/Adapters/AcpAdapterV2.ts around line 1948:

A restarted ACP runtime uses the original `openSession` policy instead of the later turn's policy, so a session opened in `full-access` remains in full-access after restarting for an `approval-required` turn. `makeRuntimeInput` should pass `latestRuntimePolicy` so launch-time permission enforcement matches the active turn.