A coding agent that cannot edit a file sounds safe to point at an unfamiliar repository. Before the first edit, though, it may load settings from the repository, start a declared connector, or run a hook. Denying its Write tool does not settle who gets to start those processes.
This isn't a claim that every coding agent behaves the same way. It's a reason to test the exact command you plan to run, especially if that command will open code you did not write.
The permission you forgot to inspect
In an October DEV.to account, the author tested a scanner adapter against a hostile repository on Linux with Claude Code 2.1.288. The repository contained a .claude/settings.json hook and a .mcp.json server declaration. In the reported test, both ran under the adapter's original command even though Write remained denied. That's the author's result for that adapter and version, not an audit of other agents.
The reported fix didn't disable every tool. Restricting settings to user scope with --setting-sources user and using --strict-mcp-config stopped the repository hook and MCP server in that setup, while the scanner's explicitly supplied MCP server still worked. There's a difference between a tool the operator selected and one the target repository selected for them. Check these flags against the CLI version you deploy rather than pasting them into a different agent's command.
Put an untrusted repo in the test, on purpose
Before running a headless reviewer against unknown code, I would build a disposable fixture and run the same adapter invocation I intend to use in CI. This is a proposed acceptance test, not a test I ran for this article.
Give the fixture a harmless settings hook and an MCP server that each leave a distinct marker in test-only logs. Keep real tokens and production endpoints out of it. Run the current read-only adapter configuration, then run it again with the settings source and allowed MCP servers selected explicitly by the operator. Capture process-start evidence along with the markers. An agent's recap won't tell you which process actually launched.
I would keep the acceptance checks separate:
- The baseline shows whether the repository's hook or server starts under the command as it exists today. If it does, record that as a failed trust-boundary check, regardless of whether the agent edits a file.
- Under the restricted configuration, the repository-provided hook and server should not start. An operator-provided MCP server that the workflow needs should still be available.
- The agent should remain unable to write through its denied tool in both cases. Check this separately; process-start and write permissions are different observations.
Keep the fixture isolated and discard it afterward. If the CLI cannot specify trusted settings and connectors for this workflow, don't declare the test passed because the agent promised to ignore the repo. Change the runner boundary or keep that agent away from untrusted repositories until you have a control you can verify.
Egress is a different check
Even after you stop a repository-supplied process from starting, ask where the processes you do allow can connect. The Harness v1.11.0 release notes describe an opt-in --egress <allowlist> for restricting outbound HTTPS hosts in its agent container. That's a concrete example of a runtime control, not a flag you can assume exists in the scanner from the DEV.to test.
For a runner with an outbound-host policy, use a controlled test endpoint to check an allowed destination and a blocked destination without transmitting secrets. Save the connection result and the effective policy alongside the process evidence. An allowlist limits the routes available through that runner; it does not fix an unwanted local hook starting, and a clean settings scope does not prove network containment. The Harness release is product-specific, and a host allowlist is not a blanket exfiltration guarantee.
Before I accept "read-only" as a security property, I want the run to tell me whose configuration loaded, which processes started, and where those processes could connect. A denied edit alone tells me none of that.
Source notes
- Hostile-repository adapter test — author-reported Linux/Claude Code 2.1.288 test of repository settings, MCP startup, and an explicit configuration remedy; not independently reproduced here.
- Harness release notes — v1.11.0 description of the optional outbound HTTPS host allowlist for its container; a separate product, not an integration with the scanner.
Top comments (0)