Claude Code Adds Shell Startup Guards: What the New acceptEdits Security Model Means for Headless Deployments

If your team runs Claude Code in headless or SDK mode with acceptEdits enabled, the June 2 release changed your security surface without changing your config. New interactive prompts now gate writes to shell startup files and build-tool configuration files — and if your pipeline assumes those writes are silent, it will stall.

What changed

The June 2 Claude Code release (v2.1.157+) introduces two layered security interventions aimed at preventing AI-generated code from unintentionally granting itself persistent execution privileges:

Shell startup file guard. Before writing to .zshenv, .zlogin, .bash_login, or ~/.config/git/, Claude Code now presents an explicit prompt. These files execute on every shell open — a successful write could install a persistent hook that runs arbitrary commands as the user, well beyond the scope of the current Claude Code session. The guard is unconditional: it fires regardless of acceptEdits state.

acceptEdits build-tool config guard. Teams that enable acceptEdits mode — where Claude Code automatically merges file edits without per-edit approval — now see an additional confirmation layer for a class of files that can grant code execution. The guarded list includes:

• .npmrc and .yarnrc* — can define lifecycle hooks and install scripts
• bunfig.toml — same class, Bun toolchain
• .bazelrc — can specify custom toolchain executables
• .pre-commit-config.yaml — executes hooks before every commit
• .devcontainer/ — defines the full container environment including startup scripts

These are not cosmetic configs. A maliciously or accidentally crafted .npmrc with a scripts.preinstall hook, for example, would run arbitrary code on every npm install in that repository. The new guard prevents acceptEdits from treating these files like any other source file.

Why it matters for AI engineering teams

The acceptEdits pattern is common in autonomous coding-agent deployments. Teams configure Claude Code as a background agent — launched via the SDK, triggered via CI, or routed through an API gateway — and rely on it to make and merge changes without pausing for human approval. This is how you get throughput; it's also how a compromised prompt or an edge case in the model's judgment could silently write a hook into your developer environment.

The new guards break the implicit assumption that acceptEdits is a flat blanket. It now has file-class carve-outs for anything in the execution-chain. For most teams doing application code, this is invisible. For teams running infrastructure-as-code agents, scaffold generators, devcontainer updaters, or pre-commit hook managers, it is a workflow change.

The removed CLAUDE_CODE_OPUS_4_6_FAST_MODE_OVERRIDE environment variable is also worth noting: any pipeline that set this override to force fast mode on Opus 4.6 deployments will silently stop having any effect. The variable is now a no-op, but it will not throw an error — leaving a configuration that does nothing.

The router/operator angle

SDK and gateway deployments. When you deploy Claude Code via the Claude Code SDK (@anthropic-ai/claude-code) behind an API gateway or TheRouter, the tool-call stream still routes normally. What changed is what happens inside the Claude Code subprocess when it attempts to write a build-tool config: instead of emitting a write tool-call that proceeds silently, it will emit a prompt that blocks until a human confirms (or times out).

If your infrastructure wraps Claude Code with --yes or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 and no human is in the loop, you need to verify whether your deployment will now receive unhandled prompts. The prompt is not exposed as an API error — it surfaces at the TTY level. Headless runners that capture only stdout/stderr may not see it and will simply hang.

acceptEdits scope audit. This is the right moment to audit which file patterns your Claude Code agents are currently allowed to write. The model does not restrict itself to application code by default. If you have not configured explicit ignore patterns or file-scope constraints in your CLAUDE.md or settings.json, your agents may have been writing to build-tool configs already. The new guard catches this going forward but does not retroactively audit what has already been written.

Dynamic workflow keyword change. The trigger keyword for dynamic workflows changed from workflow to ultracode. Any SDK integration or prompt template that triggers dynamic workflows by sending the literal word workflow as a prompt prefix will now fail silently — the request will be processed as an ordinary turn rather than a dynamic workflow run. Check CLAUDE.md files and SDK wrapper prompts if you use this feature.

What to watch

• Verify your headless pipelines. Run a test turn that would trigger a build-tool config write in a staging environment. Confirm whether your runner handles the new prompt or hangs.
• Audit acceptEdits file scope. Use settings.json to whitelist specific directories or file patterns if your agents have legitimate reasons to update .npmrc or devcontainer configs. Explicit scope is safer than relying on the model's judgment.
• Remove CLAUDE_CODE_OPUS_4_6_FAST_MODE_OVERRIDE. If any pipeline sets this, strip it — it is a no-op that could mislead future debugging sessions.
• If you use dynamic workflows, update any hard-coded workflow keyword triggers to ultracode.

The broader pattern here is that Claude Code's security model is maturing from "trust the model to stay in scope" toward explicit file-class governance. Operators who treat Claude Code as a black box and route all of its tool calls through an API layer should expect more of these file-write boundaries, not fewer, as the model is deployed in higher-stakes environments.