Claude Code changes permission defaults for unattended jobs

Anthropic’s October 16, 2026 update changes how some Claude Code jobs get permission to act when nobody is at the keyboard. Teams running background scripts or applications should check whether they have left that choice implicit: affected jobs now start in manual-approval mode instead of automatic assessment.

Which jobs are affected

In Claude Code 2.1.302, unattended command-line runs (claude -p) and Agent SDK sessions with no permission mode selected start in default mode when using a third-party provider, running with telemetry off or starting from a fresh install. This is a change to an omitted choice, not a blanket change to every interactive session.

The TypeScript Agent SDK 0.3.302 release confirms the same behavior when permissionMode is omitted. Both release notices say automatic assessment remains available through explicit selection, subject to the mode’s access requirements.

As of October 16, the general permission-mode documentation still describes the earlier unattended default in these environments. For the changed starting behavior in 2.1.302, use the versioned release notice rather than that older description.

Choose who approves actions

The useful deployment decision is who should authorize actions that need approval: your application or a person, a predefined rule, or a model-based check.

• Keep application or human approval: select --permission-mode default on the command line, or permissionMode: 'default' in TypeScript. This mode adds no automatic approvals of its own; configured rules still apply. Provide a working approval route for actions those rules do not resolve. Anthropic’s SDK permission guide explains that evaluation order.

• Run a narrow job without waiting for input: consider --permission-mode dontAsk with narrowly scoped --allowedTools rules. Calls needing a prompt are denied. But allowedTools preapproves matching calls; it does not remove every unlisted tool. Operations that need no prompt can still run. Use disallowedTools in the SDK for explicit exclusions, as described in the allow and deny rules. This is permission configuration, not an operating-system sandbox.

• Retain automatic assessment: select --permission-mode auto or permissionMode: 'auto', as the new release notes specify. Auto uses a model to assess actions requiring that check; it is not permission bypass. Check supported models, providers and organizational policy before choosing it. Explicit selection does not guarantee that every action will be approved.

Cost also depends on where those checks run. Anthropic says server-side checks have no separate classifier charge, while client-side fallback can add billed token usage on affected accounts. That does not make the underlying model’s work free.

Review the rules as well as the mode

Do not assume that changing from auto to default simply removes authority. Anthropic documents that entering auto drops broad execution allow rules, while narrow rules remain. Since default still honors configured approvals, the practical implication is to inspect inherited rules alongside the selected mode.

An application’s approval callback, canUseTool, is not a checkpoint for every action: earlier approvals can prevent it from being called. Where a check must run before a tool executes regardless of automatic approval, use an appropriately matched PreToolUse hook. Review its coverage rather than assuming the callback sees everything.

Check what the job actually did

Start with the runtime doing the work. The TypeScript SDK normally bundles its own Claude Code executable, unless an override is configured. Its initialization message reports claude_code_version and permissionMode. Record both; checking a separate terminal installation does not establish what the application used.

A missing approval route does not necessarily leave an unattended job waiting. The SDK reference says a run with neither an approval callback nor a permission-prompt tool denies calls that would require approval, unless a PermissionRequest hook allows them. By contrast, a supplied callback can remain pending indefinitely until the application responds.

Inspect permission_denials in the final result—the SDK’s authoritative denial record—and check the expected outputs. The operational implication is that a final answer alone does not establish that every required action ran.

Before production rollout, try a bounded staging task with one action intended to be allowed and another intended to be denied, then inspect the resulting state. Keep the intended privacy settings and approval policy; do not switch to permission bypass merely to make a blocked task proceed.

For a different approval problem, RohitAI’s earlier guide to lost cloud permission replies covers delivery of human responses. This update concerns which permission mode an unattended job starts in.