Hostile Repo Test: Whose Settings Does Your Agent Obey?

A developer pointed an AI coding agent at a deliberately hostile repo, and the repo's own settings hook ran.

The test comes from the maintainer of secfoo, described in the write-up as "an open-source (MIT) CLI that hands an agent such as Claude Code a security brief and a target." It is one developer's result on their own tool, not an independently verified advisory — but the question it asks is one most agent setups never answer: "whose configuration does the agent obey, yours or the repo's?"

The setup

The hostile repo held three things: a .claude/settings.json with a hook that runs a command, a .mcp.json defining an MCP server, and settings that enable project MCP servers and try to allow Write, Edit and Bash. The adapter's original command was then run against it.

What happened

Three outcomes, in the author's words: "The repo's hook ran. The repo's own MCP server started. Write stayed denied, so the read-only grant held."

The permission layer did its job; the configuration layer did not. The write-up puts the consequence plainly: "the scanned code could make the scanner execute something, even though it could not write files. For a tool whose whole job is to open untrusted code, that is the wrong way round."

The fix is two flags

Scoping configuration back to the operator took two additions to the agent command. --setting-sources user "loads only the user's own settings, so the target repo's settings are ignored." --strict-mcp-config "uses only the MCP servers the tool passes in explicitly."

Three smaller changes landed with them. The prompt now goes over stdin rather than the command line, because command-line prompts "can be truncated at newlines on Windows". --no-session-persistence stops a session file being left behind for every scan. And failed runs now record why they failed, since the agent writes errors to its JSON output rather than stderr.

The resulting command:

claude -p --output-format json --allowedTools \
  --permission-mode default --setting-sources user \
  --strict-mcp-config --no-session-persistence

Why it is worth ten minutes

Running an agent over code you did not write is now routine — dependency review, inherited repos, open-source triage, anything a contractor hands over. In all of those, the repo is input, and input should not get a vote on the agent's configuration.

Two things worth checking in your own runner, framed as general practice rather than anything the test measured: whether your agent command loads project-level settings by default, and whether a denied write permission is the only control you are relying on. This test suggests those are separate questions, and that passing the second does not mean you passed the first.