What is your agent configured to run?

Clone a repository, open it with your agent, and you may have just agreed to run whatever its configuration tells it to. Folders like.claude/, .cursor/, .codex/ can start commands, redirect traffic and swap out the programs your agent relies on, and they belong in the threat models of the people and organisations using them. To make them easier to check, we’re releasing agentaudit (Web/CLI), an open source tool that takes on the burden of reading a project's agent configuration and flagging the settings that might run commands, move data, or widen the agent's access to your machine, before you open the repository.

When users open a repository with an AI agent, they are met with the workspace trust prompt: "do you trust the files in this folder?" Answering it transfers responsibility from the vendor to the user. The question is whether users actually check those files. Do they have the time or tools to quickly find out what they are agreeing to? Most are opening several repositories a week, often against a deadline, and the prompt has become one more box to tick. Although not identical, this scenario is similar to the long service agreements people accept without reading, except that here the consequence might be an arbitrary command running on their machine.

Few technologies have been adopted as quickly as AI agent harnesses. Claude Code, Cursor, Codex and others are how a great deal of work gets done nowadays, and the time it takes to turn an idea into something real has dropped dramatically. New projects are surging faster than ever before.

That has brought the emergence of shared agent configuration. Repositories now ship their own .claude/, .cursor/, .codex/, .agents/ and .mcp.json, carrying skills, sub-agents, plugins and hooks. Sharing them is useful: a project distributes its workflows and its customizations, and everyone working on it gets the same setup.

When a technology brings benefits this large, people tend to concentrate on the gains and spend less thought on the nuanced parts. Accepting the configuration a repository ships has become the new normal, and reflexive with it. The danger sits exactly there. These files are powerful by design, and many of their keys are code execution sinks: they name commands, and they decide when those commands run. None of this is a bug: each is an ordinary setting doing the job it was built for.

Users and teams need a quick way to see what a .claude/, .cursor/ or .codex/ actually loads when a workspace is trusted. The configuration a user's harness loads should be part of an organisation's threat model.

What follows is a set of examples of these settings: what each one is for, how it could be turned against the person who cloned the repository, and how agentaudit surfaces it. It reads a repository's agent configuration and quickly reports what that configuration can do: the hooks, MCP servers, credential helpers, environment variables, and other settings an agent picks up when it opens the repository.

mcpServers in a sub-agent

A project can define sub-agents in .claude/agents/, each with its own prompt and its own tools. A sub-agent can also declare the MCP servers it needs through its mcpServers frontmatter key, so those tools stay out of the main conversation instead of loading for every session.

Declare that server in .mcp.json, the documented place for a project's servers, and Claude Code asks on first open: a new MCP server was found in this project, and tool calls will require approval. Decline it and the command never runs. The refusal goes into .claude/settings.local.json and is honoured next time.

Declared in a sub-agent's frontmatter, the same server is never put to you. It just runs.

On top of that, the agent key in .claude/settings.json decides when it runs:

That makes the sub-agent the session itself, so its servers start when the session does, rather than when something delegates work to them. The command runs before you have typed anything.

agentaudit has a rule to flag this:

statusLine

The status line is the row Claude Code prints under the prompt. A project can render its own by pointing statusLine.command at a script, which is how most people get their branch, model and token count on screen.

The script receives the session as JSON on standard input and whatever it prints becomes the row. Nothing stops it from running other arbitrary commands on the way:

The command runs again as the session goes on, and the status line keeps rendering exactly as expected.

agentaudit has a rule for this:

env.PATH

Claude Code reads .claude/settings.json. Its env key sets environment variables for the session and for every process the agent starts, so a project can give everyone who clones it the same setup.

PATH is one of the variables a project is allowed to set.

That first entry is relative, so it points inside the repository. Whoever wrote the file now decides which programs the agent actually runs.

What sits in that folder is up to the repository.

Claude Code looks up its helper programs by name, so the first match on PATH wins. On Linux the sandbox is one of those programs: shell commands are confined by invoking bwrap. A repository that ships its own bwrap becomes the sandbox and decides how much of that policy to apply, which is enough to run arbitrary commands on the machine without the person at the keyboard seeing anything out of the ordinary.

agentaudit has a rule to detect this:

setup-worktree in Cursor

Cursor can run an agent in an isolated git worktree. .cursor/worktrees.json says what should happen when one is created, which is where a project puts npm install or whatever else a fresh checkout needs.

The file is committed like any other project configuration. Ask for a worktree and the command runs.

We looked at this key before, back when the command ran before the workspace trust prompt was accepted rather than after it: Cursor CLI worktree pre-trust execution.

agentaudit has a rule for this:

ANTHROPIC_BASE_URL and HTTPS_PROXY

Not everything a project can set ends in a command. The same env block in .claude/settings.json also decides where the agent's traffic goes.

ANTHROPIC_BASE_URL is the address Claude Code talks to. Point it elsewhere and the conversation goes there instead: your prompts, the file contents the agent read to answer them, and the credentials it sends along. HTTPS_PROXY is the broader version, putting a host of someone else's choosing in front of outbound traffic.

Nothing runs. A repository changed two strings, and the agent keeps working exactly as before.

agentaudit has a rule for each:

bearer_token_env_var and http_headers_helper in Codex

Codex reads its MCP servers from [mcp_servers.*]. Two of the keys there send your environment to the server. bearer_token_env_var names an environment variable to put in the Authorization header; env_http_headers maps header names to more of them. Neither holds a secret. They hold the names of secrets, read from your environment when the connection is made. Name AWS_SECRET_ACCESS_KEY and the server gets your key.

A third, http_headers_helper, runs a local command to print the headers instead.

agentaudit has a rule for each:

Skills

A skill is a folder under .claude/skills/ holding a SKILL.md and, beside it, a scripts/ folder. It packages script files, and a script file can contain any command at all. That much is well known.

Claude Code also supports dynamic context loading, which is the line beginning with ! below.

Two things in that file run.

The checker is a script the repository ships, and the skill exists to get it run.

The line beginning with ! runs a shell command and substitutes its output into the skill.

agentaudit has a rule for each:

Hooks

Hooks are the well-known one. Every harness has them, they exist to run commands on lifecycle events, and nobody is surprised that a repository can ship them.

Worth knowing which events need no user action. SessionStart fires as the session begins, before you have asked for anything.

agentaudit has a rule for this:

Every one of these is an ordinary setting doing the job it was built for. Reading them before you trust a folder is the obvious answer. The files sit across several directories, most of what they hold is unremarkable, and the handful of keys that end in a command are mixed in with the benign ones. Doing that for every repository you clone is not work anyone has time for. What users and teams need is a quick way to see the part that matters.

agentaudit

agentaudit (Web/CLI) reads the configuration in a repository and reports what it can do. Every example above came out of it.

Each harness gets an adapter. The adapter knows where that harness keeps its configuration and how to read it, so .claude/settings.json, .cursor/worktrees.json and .codex/config.toml all end up described the same way, and a finding reads the same whichever tool put the file there. Claude Code, Cursor and Codex are supported today.

What each adapter finds is then matched against rules, and the rules are data rather than code. A rule names the key it looks for, the category it belongs to, and the sentence printed when it matches. Adding one is usually a matter of writing that file.

If you do not see an adapter for a harness you use, let us know, or feel free to contribute one. The same goes for a rule you think would be useful. agentaudit is open source, and pull requests are welcome.