M1: say that the automation roots reach only the headless side (#835)

The CLI help and docs/mcp.md described the roots as confining whatever the run
touches, which reads as if they also applied to `mcp --attach`. They don't: an
attached server runs the commands inside the app, and the app confines them
from its own flags. VectorCraft documents the same split, and the missing
sentence is what made the difference confusing, as #835 reports.

Co-authored-by: xiaou61 <113765024+xiaou61@users.noreply.github.com>
This commit is contained in:
xiaou61
2026-10-20 11:08:21 +08:00
parent dd6bd3fe1c
commit ea2fa7c367
3 changed files with 12 additions and 5 deletions
+3 -1
View File
@@ -186,7 +186,9 @@ Serve MCP on stdio: headless by default, or attached to a running app started wi
`figcraft --control PORT`. See [mcp.md](mcp.md). The automation roots (each repeatable; existing
folders) confine the files the agent's calls read (inside a read or write root) and write (inside a
write root); everything else is refused ([mcp.md › Confining file access](mcp.md#confining-file-access)).
With `--attach` they are refused: start the app with them instead. The headless session can host, join and publish
They apply to the headless session only, and that is why `--attach` refuses them: an attached server
is confined by the app it attaches to, from the flags that app was started with. The headless
session can host, join and publish
live sessions (`collab.*`: without a key on a server open to the public, with `collab.serverInfo`,
`collab.manageFile` for the owner token and `collab.report`) and use plugin directories
(`plugin.directory.*`); the one-shot `run` can't (no network link).