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

docs/user/permission-modes.md

@@ -21,11 +21,16 @@ not prevent the agent from asking questions about the task.
 ## Provider differences
 
 Providers enforce permissions differently. Some read-only actions can proceed in **Supervised**.
-**Auto** uses automatic review on Codex, Claude, and Cursor; providers without an equivalent,
-including OpenCode and Antigravity, fall back to asking.
+**Auto** uses automatic review on Codex, Claude, Cursor, and Grok; providers without an equivalent,
+including OpenCode and Antigravity, fall back to asking. On Grok, commands its review blocks come
+to you for approval.
 
-For Grok, **Always allow this session** remembers the matching command or tool input. Other
-actions still require approval.
+Grok offers no **Auto-accept edits**. A Grok thread already set to it runs in **Supervised**. For
+Grok, **Always allow this session** remembers the matching command or tool input. Other actions
+still require approval.
+
+ACP Registry agents run their own tools in their own mode; T3 Code answers their approval requests
+by the permission mode. See [ACP Registry permissions](./providers-acp.md#permissions-and-terminals).
 
 Antigravity can still send native approval requests in **Full access**. It only offers remembered
 approvals for actions that support them.

docs/user/providers-acp.md

@@ -90,17 +90,19 @@ instead of disappearing.
 
 ## Permissions and terminals
 
-Registry agents follow the thread's approval mode at the T3 client boundary: full-access threads
-approve mediated permission requests automatically, while approval-required threads keep asking
-before edits and commands. File reads and searches are never gated behind an approval prompt.
-For ACP v1 agents, T3 can mediate the file and terminal requests they send through the client. ACP
-v2 terminals are instead owned by the agent; T3 displays their command, output, and exit state when
-the agent publishes them, but does not execute or control those terminals.
-
-ACP does not let T3 Code confine tools the agent executes inside its own process. An agent may run
-provider-owned commands or file operations without passing through T3's handlers, so an ACP thread
-does not provide the same native sandbox guarantee as Codex. Use the agent's own sandbox and
-permission controls when that distinction matters.
+Registry agents read files, edit, and run commands themselves, under their own sandbox and
+approval rules. They start in their own default mode, and their mode picker in the model options
+menu switches it. How far an agent is confined depends on that mode and the agent's own settings,
+so use its sandbox and permission controls when that matters.
+
+When a registry agent asks for approval, T3 Code answers by the thread's
+[permission mode](./permission-modes.md): **Supervised** shows the request in the conversation,
+**Auto-accept edits** approves edits and shows the rest, and **Auto** and **Full access** approve
+automatically. File reads and searches never wait for approval.
+
+Devin runs its commands through T3 Code's terminals, and those commands follow the thread's
+permission mode. For other agents, T3 Code shows the command, output, and exit status the agent
+reports but does not run or stop their terminals.
 
 Registry agents can schedule work and use T3's MCP tools. Child-task presentation depends on what
 the agent exposes: ACP has no portable native subagent-lineage contract, so richer delegation views