Production Guards: CI/CD and Unattended Runs

The Non-Interactive Context Changes the Rules

In an interactive session, you are the last line of defense — you review proposed actions and approve them. In a CI pipeline or automated script, there is no human in the loop. The safety posture must be configured entirely upfront, because there is no one to approve unexpected actions or override a mistaken decision after the fact.

Claude Code in non-interactive mode (invoked with claude -p) behaves differently from interactive mode in two important ways: the workspace trust dialog is disabled (project allow rules in .claude/settings.json are not applied unless the workspace was already trusted in a previous interactive session), and repeated auto-mode classifier denials abort the session rather than pausing and asking you what to do. An incomplete allow list does not produce a prompt — it produces a failed task.

dontAsk Mode for CI

The correct permission mode for most CI pipelines is dontAsk. It auto-denies every tool call that is not explicitly in your permissions.allow list, making Claude Code's behavior completely predictable: it does exactly what you pre-approved and nothing else.

Pair dontAsk with a tight allow list that names every tool Claude needs for the specific task:

claude -p "Run the test suite and report failures" --permission-mode dontAsk --allowedTools "Bash(npm test *)" "Bash(npm run lint)" "Read" --disallowedTools "WebFetch" "Write"

Test your allow list interactively first. If Claude hits a tool call that is not on the list, the action is silently denied — the task may fail with a confusing error rather than an explicit permission message.

bypassPermissions in Containers: The Right Pattern

bypassPermissions is sometimes appropriate in CI when you need Claude to run autonomously without any prompts or classifier overhead — typically for longer tasks in ephemeral environments. The requirements are strict:

• Non-root user: Claude Code refuses to start in bypassPermissions when running as root or under sudo. Use a dev container configuration or a Docker image with a dedicated non-root user. The --dangerously-skip-permissions flag is equivalent to bypassPermissions and has the same root restriction.
• Isolated filesystem: The container should have no access to your host filesystem, credentials, or other sensitive state. Mount only what Claude needs for the specific task.
• No persistent internet access: Disable or heavily restrict network access in the container. A compromised task in bypassPermissions mode with internet access can exfiltrate anything it can read.
• Ephemeral environment: The container should be destroyed after each run. bypassPermissions in a long-running shared environment defeats its own safety model.

The dev container configuration (.devcontainer/devcontainer.json) in Claude Code's documentation provides a reference implementation of this pattern.

Auto Mode in CI

For longer autonomous tasks in CI, auto mode with --permission-mode auto provides behavioral review without per-action prompts. Unlike dontAsk (which requires a pre-defined allow list), auto mode can handle tasks where Claude needs to make judgment calls about which tools to use.

Pair auto mode in CI with a configured autoMode.environment block covering your CI infrastructure — trusted repos, internal domains, artifact registries — and deploy it via managed settings so every CI run benefits from the same infrastructure context. In non-interactive mode, repeated classifier denials abort the session, so an environment block that resolves common false positives is essential for reliable task completion.

The Recommended CI Safety Stack

A complete CI safety configuration combines multiple layers:

• Sandbox enabled with failIfUnavailable: true and allowUnsandboxedCommands: false — hard enforcement, no fallback
• Credential protection via sandbox.credentials blocking reads of credential files and unsetting sensitive environment variables
• Managed allow list (if using dontAsk) or managed environment block (if using auto mode) deployed through managed settings or --settings flag
• ConfigChange hook to prevent Claude from modifying its own settings during the run
• Stop hook for task-specific completion gates (tests pass, no TODO markers, required files present)
• CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 as a backstop for unsandboxed subprocesses

Cloud Session Security

For teams using Claude Code on the web (claude.ai/code), cloud sessions include additional security controls managed by Anthropic:

• Isolated VMs: Each cloud session runs in an isolated, Anthropic-managed virtual machine. Sessions cannot share state or filesystem access.
• Scoped credential proxy: GitHub authentication is handled through a secure proxy that uses a scoped, session-specific credential. Claude Code never holds your actual GitHub token — the proxy holds it and translates to your real token for each request.
• Branch push restriction: Git push operations in cloud sessions are restricted to the current working branch. Direct pushes to main or other branches are blocked at the infrastructure level.
• Automatic cleanup: Cloud environments are automatically terminated after session completion. No state persists between sessions.
• Audit logging: All operations in cloud sessions are logged for compliance and audit purposes. This provides an audit trail for organizations with regulatory requirements around AI tool usage.

The Security-Guidance Plugin

Claude Code's /security-guidance plugin adds a specialized agent that reviews code changes Claude makes during a session for security vulnerabilities. Enable it with /security-guidance in an interactive session, or install it as a plugin for automated review in CI workflows. It provides a second-opinion review layer specifically focused on authentication, access control, input validation, and other OWASP categories — a useful complement to the permission system's behavioral controls.