MCP: the file tools send paths made absolute against the server's working directory

With --connect, open_file, save_file, export and screenshot {path} sent a
relative path to the app unchanged, and the app resolved it against its
own working directory (/ when started from the Finder). A relative path
then named a different file than it does headless, where the server
resolves it against its own working directory.

The server now makes these paths absolute against its working directory
before it sends them, including export's options.path and the path a
screenshot reply reports. Paths inside run_command and command_batch
params go to the app as given. docs/mcp.md describes the rule.
This commit is contained in:
dotCooCoo
2026-10-24 17:29:33 +07:00
committed by bflatastic
parent 58827952b7
commit e71bf71376
3 changed files with 84 additions and 3 deletions
+4
View File
@@ -107,6 +107,10 @@ the suite) keep the agent to the folders you give it:
The result is compared with the root by whole folder names: `/work2/x` is not inside `/work`. On
Windows case is ignored, UNC paths (`\\server\share\…`) are resolved like drive-letter ones, and
device names (`CON`, `NUL`, `COM1`…) are refused.
- With `--connect`, the server makes the paths of `open_file`, `save_file`, `export` (`path` or
`options.path`) and `screenshot {path}` absolute against its own working directory before it sends
them to the app. Paths inside `run_command` and `command_batch` params go to the app as given, and the
app resolves them against its own working directory.
- A refused path is an ordinary tool error the agent can read and correct, for example
`automation path rejected: outside the write root /work/project/out: /etc/x.png` (with several,
`outside the write roots /work/project/out, /tmp/scratch: …`) or