macOS MCP audit logging: where macos-use already writes every tool call

To /tmp/macos-use/ on the host that runs the server. Every CallTool handler creates that directory with FileManager.default.createDirectory at Sources/MCPServer/main.swift:1962, then writes <unix-ms>_<safe-tool-name>.txt with the full flat accessibility tree, plus <unix-ms>_<safe-tool-name>.png with a window screenshot. The path is also returned in the JSON-RPC response as the 'file:' line, so the model that just called the tool always knows exactly where the evidence landed. No env var, no flag, no opt-in. It is on by default.

A flat one-element-per-line dump of the post-action accessibility tree (and the pre/post diff for click, type, scroll, press). Each line is '[AXRole (role description)] "text" x:N y:N w:W h:H visible', plus a header with the app name, element count, and processing time. The format is built by buildFlatTextResponse and formatElementLine in main.swift. The diff sections are tagged with + for added nodes, - for removed, and ~ for modified attributes (main.swift:1029-1047), so you can reconstruct what the agent changed about the UI without replaying anything.

A PNG of the target window captured by the screenshot-helper subprocess immediately after the action runs. captureWindowScreenshot in main.swift:389-510 picks the on-screen window with the best score for the PID the tool acted on, then forks an out-of-process helper to write the PNG to /tmp/macos-use/<unix-ms>_<tool>.png. The click point and window bounds are passed in, so a red dot can be drawn on what the agent clicked. If the screenshot helper is missing or times out, the .txt still gets written; the audit trail degrades gracefully to text-only rather than failing the call.

Yes. The writeout happens inside the CallTool handler before the response is returned (main.swift:1968 'try? resultTextString.write(toFile: filepath, atomically: true, encoding: .utf8)'). Atomically means the file is written to a temp path and renamed in place, so a crash mid-write leaves either the complete file or no file, never a torn one. If the MCP client crashes after the tool finished but before it read the response, /tmp/macos-use/ still has the .txt and .png. You can replay the session by ls-ing the directory in timestamp order.

macOS clears /tmp/ on reboot via launchd and the periodic cleaner in /etc/periodic/daily/110.clean-tmps, which deletes files older than 3 days (the +mtime +3 rule in that script). To keep your trail, run a one-line rsync on a launchd interval: 'rsync -a /tmp/macos-use/ ~/Library/Logs/macos-use/'. The .txt files compress to roughly 10-20% of their on-disk size with gzip because the accessibility tree is repetitive. A second cron job that does 'find ~/Library/Logs/macos-use -name '*.txt' -mtime +1 -exec gzip {} +' will keep the long tail readable without blowing through disk. For SIEM ingestion, tail the directory with fswatch and pipe new files into your collector.

The filename timestamp is Unix epoch milliseconds (Int(Date().timeIntervalSince1970 * 1000), main.swift:1964). Cross-reference it against Claude Code's session log under ~/.claude/projects/<encoded-path>/sessions/<uuid>.jsonl, which records every assistant turn with its start time. For Cursor, the equivalent is the chat history file in the workspace state. The MCP server itself does not carry a session ID; correlation lives at the client. If you need first-class session attribution, fork the server and add a session header to the env (Claude Code passes env vars through to the spawned MCP process).

Two specific gaps. (1) The raw MCP request arguments are logged to stderr ('log: handler(CallTool): arguments received (raw MCP): ...' at main.swift:1550) but are not folded into the .txt file. If your stderr is going to /dev/null because Claude Code suppresses it, you lose the 'what did the agent ask for' half of the audit. (2) Cancelled tool calls (the user pressed Esc, InputGuard fires) emit a 'log: handler(CallTool): user cancelled' line to stderr (main.swift:1988) but do not write a .txt for the cancelled action; only completed and errored calls leave a file. Both gaps are 20-line patches if you need a tamper-evident, complete trail.

No, the directory is created with default permissions (drwxr-xr-x, owned by the user that ran the MCP server). Other local users can read the files but cannot write or modify them. If you want to harden this further, move the output dir to ~/Library/Logs/macos-use/ in your fork (it is a one-line change at main.swift:1961) and the directory inherits ~/Library/Logs/ permissions, which are owner-only. The host process needs Accessibility permission to capture the AX tree at all, so a non-admin user on the machine cannot scrape a trail from another user's MCP session without already having sudo.

Yes, by default, every tool call that succeeds against a window produces a .png of that window. If you are driving 1Password, Mail, Slack DMs, or a banking site, the rendered pixels of that window end up on disk in /tmp/macos-use/. If that is not acceptable for your environment, pass an env var check around the captureWindowScreenshot block at main.swift:1977-1979 in your fork ('if ProcessInfo.processInfo.environment["MACOS_USE_NO_SCREENSHOT"] == nil { ... }'). The .txt accessibility tree will still contain element text (typed-in fields, visible labels), so a text-only audit is not the same as no audit.

Different layers entirely. auditd captures kernel-level events: file opens, process execs, syscalls, login attempts. It does not know what an MCP tool call is, and it does not see what the model asked the agent to do. The /tmp/macos-use/ trail captures the application layer: which AX element was clicked, what the window looked like after, what changed in the tree. For a complete picture you would want both. auditd answers 'did anything weird touch the filesystem?'; /tmp/macos-use/ answers 'what did the AI agent click?'. The two never overlap and the second is not redundant with the first.