Claude Code Security: What Actually Runs Before You Trust a Folder

A coding agent asks whether you trust a folder, you answer, and that answer covers the route you just took. Straiker STAR Labs says a different route into the same folder never asked. The interesting part of that claim is not whether one product has a bug. It is that the vendor's own documentation now publishes, in a table, exactly which repository content runs before you have trusted anything.

What follows takes apart a research post dated 8 October 2026. It is a single vendor's finding, not reproduced here, and the account of events comes from Straiker's write-up alone. Detail that would help somebody repeat the sequence is left out deliberately. No statement from Anthropic about that specific report has been located, so the second half of this article works from product documentation rather than from a response.

What Straiker Published, and When

Date	What the post states	Attributed to
27 August 2026	The behaviour is found	Straiker
17 September 2026	Filed through HackerOne, and closed the same day with an informative rating	Straiker
8 October 2026	The post goes public	Straiker STAR Labs
Not established	Anthropic's own reading of the report, or any product change following it	Nothing located

Per the post, the triage treated trust in a repository's settings as falling inside the workspace-trust decision the user already makes. Two competent engineers can land on opposite sides of that boundary question. The design lesson underneath survives either answer, which is why it is worth the time.

Four Steps, No Jailbreak

1. One session can start another. A shell tool starts programs, and a coding agent is a program. The post describes a session launching a second session inside a repository that had not been trusted, reached through an ordinary request rather than through any injected instruction.
2. The confirmation covers its own route. The authors are explicit that the workspace-trust dialog behaved correctly on the path it sits on, and that attempts along that path were stopped.
3. The second session reads the repository's configuration. Started from the shell in the same directory, it came up without that dialog, and the project's settings applied at startup.
4. Startup code sees the environment it starts in. In their demonstration a startup handler collected environment data and pushed it to a host they ran. They report that the model noticed the activity after the data had already left, and they describe that as detection rather than prevention.

Anyone who has worked on web applications has seen this shape before: the check lives in the interface and not in the thing the interface calls. A dialog attached to one way of changing directory protects that way of changing directory, and makes no promise about an equivalent action phrased differently.

The configuration half matters as much as the session half. Claude Code's hooks documentation lists the places a hook can be declared, a project's own settings file among them, and notes that handlers execute in the current directory with the agent's environment around them. A repository is therefore able to carry commands, and those commands see whatever that environment holds. For a project you wrote, that is the feature. For one you cloned ten minutes ago, it is the exposure. The documentation moves, so read the live version rather than a quotation of it.

Severing Each Step

Step	What ends it	Owner	Cost
A session starts a session	Record process launches out of agent workspaces and alert when an agent binary is invoked from inside one. Our guide to session logging and forensics covers what to capture	Security	Medium
The confirmation covers one route	Bind approval to the consequence, which is that project-supplied commands are about to execute, rather than to the gesture a person normally makes	Vendor, with the platform team	Depends on the vendor
The second session reads project settings	Establish whether a launched session inherits the trust state of the one that launched it, and pin the answer with organisation-level managed settings	Platform team	Low to medium
Startup code reads secrets	Give the container only the credentials the task consumes, keep long-lived cloud keys out of the shell environment, and allowlist outbound destinations	Developer platform	Medium

Simon Willison's framing of the lethal trifecta is the cleanest way to hold the last row: private data, contact with untrusted content, and a way to send things out. A repository somebody else wrote is the untrusted content. Your shell environment is the private data. Outbound network is the third leg, and removing any one of the three weakens the whole arrangement. Isolation patterns sit in our sandboxing architecture write-up, and the reason environment variables are the first thing anything goes looking for is covered in how coding agents give up API keys quietly.

The Trust Dialog Has a Published Exception List

This is the part worth the reading time, and it did not exist in this form when the research came out. Claude Code's permissions documentation carries a table headed by the question of what runs before you trust a folder, covering two situations: you trusted only a parent directory, or you ran a non-interactive session where the dialog never appears at all. The rows are not reassuring, and they are not meant to be.

Hooks declared in settings files, the environment block, helper commands such as the API key helper, and a project skill's own hooks are marked as used in both situations. The documentation states that workspace trust never gates a skill's allowed tools in any session. By contrast, the allow rules and extra directories a repository proposes are held back until the dialog is accepted. The asymmetry is the whole finding, restated by the vendor: the things a repository can make run are treated differently from the things a repository asks permission for.

Two more rows deserve attention. In a non-interactive run, servers declared in a project's MCP file connect without asking, whether approved or not, while an interactive session with only a parent folder trusted prompts before connecting and ignores the repository's own approvals. And a header helper attached to such a server does not run until the folder is trusted, with the server connecting on its static headers until then. None of this is hidden. It is a documented matrix that most teams have never read.

The documentation also names the flags that close the gap, which turns this section into something actionable rather than alarming. Before running a non-interactive session in a repository you did not write, the guidance is to restrict setting sources to your own, start in bare mode so no hooks, skills, commands, subagents, plugins or project MCP servers load, and pass the hooks-off setting on the command line. That last point carries a trap worth repeating: setting it in your user settings is not sufficient, because a project's settings take precedence and can turn it back on. There is also a named entry for rejecting a project MCP server by name across every session type.

Hooks Run With Your Full Access, Sandbox or Not

The second thing that changed is the sandbox, and it needs reading carefully for what it excludes. The documentation describes an operating-system boundary around shell commands and the processes those commands start, enabled from a slash command, using Seatbelt on macOS and bubblewrap with socat on Linux and WSL2, with native Windows running commands unsandboxed. That is a real control and it is the right default to turn on.

Now the exclusion list. Command hooks, local MCP servers, plugin monitors, language-server processes and helper commands run outside the sandbox with your full access, as do the built-in file and web tools, which follow permission rules instead. Read that against the four steps above. The step that moved data in Straiker's demonstration was a startup handler, and a startup handler is precisely the category the sandbox does not cover. Enabling the Bash sandbox and believing the hook problem is solved is the mistake this section exists to prevent.

The documentation says what to do about it in one line: to put those processes behind a boundary as well, run the agent process itself inside a container, a virtual machine or the sandbox runtime, with the network allowlist narrowed to hosts you approve. It also warns that filesystem and network isolation only work together, because without network isolation a compromised agent can send sensitive files out, and without filesystem isolation it can modify system resources to regain network access. Widening one side quietly undoes the other.

Two further details change how you brief a team. The working directory boundary is itself a permission prompt, so a Bash command you approve can still write anywhere your account can, which is the same lesson as the trust dialog in a different costume. And reviewing a project's MCP file does not reveal every server a session can load, because other scopes, connectors and plugins contribute servers from outside the repository.

Stop Asking Whether It Was a Bug

Teams spend the week after a disclosure like this one arguing about the triage rating. That argument is close to worthless, and the reason is that the vendor has already answered the question in documentation rather than in a response. The exception table exists. Hooks apply where allow rules do not. Non-interactive sessions never see the dialog. Hooks and local MCP servers sit outside the sandbox. All of that is published behaviour with named flags to change it, which makes the useful question operational rather than ethical: which of those documented paths is live in your environment this week, and who checked.

The judgement that follows is about where to put effort. Reading the exception table and the sandbox exclusion list, then setting the handful of flags they name, is an afternoon of work with a deterministic outcome. Waiting for a vendor to re-rank a report is not work at all. Detection has its place, and it is the place Straiker's own demonstration found it in: the activity was noticed after the data had moved. Treat an alert on an agent launching an agent as valuable telemetry and a poor boundary, and put the afternoon into the flags.

Suppose a vendor shipped trust state that a launched session inherits by construction, with no documented category of repository content that applies before the decision, then the configuration work would collapse to a version check and detection would be the only remaining lever. The position also weakens for a team that never opens a repository it did not write on a machine holding real credentials. That team has already removed one leg of the trifecta, and the rest of this is hygiene rather than exposure.

Six Things to Verify Before Friday

• List every file type your agent reads out of a project and then executes or obeys: hooks, skills, subagent definitions, MCP server declarations, plugin manifests, rules files. Anything whose gating you cannot describe is ungated until proven otherwise.
• Read the exception table in the permissions documentation against your own usage, and decide specifically whether anybody runs non-interactive sessions in repositories they did not write.
• Check whether your standard launch sets bare mode, restricted setting sources and the hooks-off setting, and confirm those are set on the command line rather than only in user settings.
• Turn on the Bash sandbox with both filesystem and network isolation, then write down which of your actual risks sit in the excluded categories.
• Establish what a startup handler would find on a developer machine: cloud keys in the environment, an authenticated git remote, a running SSH agent, live browser sessions.
• Add a detection rule for an agent process starting another agent process, and route it somewhere a human reads.

What the Record Leaves Open

Whether Anthropic accepts Straiker's reading is not established here, and no response to that specific report has been found. Whether the behaviour changed afterwards is equally unestablished. The finding has not been reproduced, and the demonstration ran in the researchers' own setup, so what it would mean in a given environment depends on that environment. How widespread the pattern is across other coding agents is also unknown, though the general lesson travels to anything that reads project configuration and can start further processes. Our separate teardown of the session-inception report stays closer to the original claims.

One adjacent development is worth noting without overreading it. On 20 February 2026 Anthropic announced a security scanner built into the web version of the product, in limited research preview for enterprise and team customers and available free to open-source maintainers on application. The announcement reports that the team found over 500 vulnerabilities in production open-source codebases using Claude Opus 4.6, and states that nothing is applied without human approval. No accuracy or false-positive figures accompany it. That is a tool for finding flaws in code the agent reads, and it is not a control on what a repository can make an agent do. Keep the two apart when somebody cites it in a meeting.

Nothing above argues for banning coding agents, and the evidence would not support it. Narrow what a session can reach, require a deliberate approval before project-supplied commands execute, and set the documented flags for repositories nobody on your team wrote. If developers routinely open third-party code on machines holding production credentials, that is a threat model to commission rather than a paragraph to read. None of this is a formal assessment of your environment.

Questions about nested coding-agent sessions

Is this a confirmed vulnerability?

It is one vendor's research post. Straiker reports filing it and reports that the triage closed it as informative. Read the original and reach your own view. The documented exception table is the more useful artefact either way.

Is this specific to one product?

The mechanism generalises to any coding agent that loads configuration out of a project and can start further processes. The flags and the sandbox exclusions discussed here are specific to one product's documentation.

What is the fastest mitigation?

Do not point an agent holding your real credentials at a repository nobody on your team wrote. Where you must, restrict setting sources, start in bare mode, and pass the hooks-off setting at launch rather than in your user settings.

Does the Bash sandbox solve this?

Not on its own. The documentation places command hooks, local MCP servers and helper processes outside the sandbox, running with your full access. Covering those means putting the whole agent process inside a container, a virtual machine or the sandbox runtime.