claude-code - 💡(How to fix) Fix Feature request: opt-in permissions.requireInteractive setting to defend against package-manager-launched Claude Code sessions

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

ummary Claude Code currently provides no built-in way to refuse tool execution when it was launched from a non-interactive context (postinstall scripts, CI hooks, child processes of package managers) on a user's workstation where headless use was not intended. The s1ngularity attack against nx in August 2025 actively exploited this gap. I'd like to propose an opt-in setting, permissions.requireInteractive, that closes it, plus a few smaller documentation and onboarding changes that would dramatically increase the adoption of existing protections. Background: the actual threat The s1ngularity supply-chain attack (nx postmortem, GitGuardian analysis) included this code path in the malicious postinstall script: bashif command -v claude >/dev/null 2>&1; then claude -p "$MALICIOUS_PROMPT" fi The relevant Claude Code behaviors at the time, still present today:

-p mode disables trust verification. First-time codebase runs do not prompt for the workspace trust dialog when stdin is not a TTY. This is documented at code.claude.com/docs/en/security but absent from the headless mode docs — already tracked as #20253, still open. --dangerously-skip-permissions is accessible by default. A user with no managed-settings file in place has no protection against a script passing this flag. Default mode still auto-approves Read, Glob, and Grep — which is most of what the s1ngularity prompt actually needed. Exfiltration was done by the malware itself, using Claude only as a file-locator. So even without --dangerously-skip-permissions, default mode is sufficient for the read-and-report portion of the attack.

In the s1ngularity case, the model's training refused many of the prompts at runtime. That is a real mitigation, but not one users can configure or rely on as a primary defense — the next variant will tune its prompt. Current state on a fresh install On a default Claude Code install (no managed-settings file, no custom hooks, default user settings):

✅ Default permission mode is default (reads only auto-approved). ✅ --dangerously-skip-permissions is verbose, no alias, refuses to run as root. ✅ CVE-2026-33068 patched in 2.1.53 (repo-controlled settings can't silently flip to bypass mode). ❌ No defense against scripts passing --dangerously-skip-permissions on the command line. ❌ No defense against the Read/Glob/Grep portion of an attack that runs in default mode. ❌ No built-in TTY or parent-process check. ❌ managed-settings.json does not exist by default and is not surfaced anywhere in onboarding. Users who want the one settings layer that cannot be overridden by a malicious repo have to discover it on their own.

Proposed Solution

Proposal Add an opt-in setting: json{ "permissions": { "requireInteractive": true } } When set, Claude Code refuses to execute any tool call (or, configurably, refuses to start a session at all) if both:

stdin / stderr is not a TTY, and the parent process chain contains a known package-manager process (npm, pnpm, yarn, npx, pip, cargo, brew, etc.), or the invocation used -p / --print without an explicit --allow-headless flag.

The setting should be available in both user settings and managed-settings, with managed taking precedence as usual. CI/CD users who legitimately need headless mode would either pass --allow-headless or set requireInteractive: false in their pipeline's managed-settings layer — the change is invisible to them. This is implementable today as a PreToolUse hook, and I've written one for my own use. But:

Most users will never know to write that hook. Hooks are not enabled by default and have no presence in onboarding. This kind of containment check benefits from being a tested, supported, first-class feature rather than user-authored bash.

Alternative Solutions

Alternatives considered

Default requireInteractive: true. Would break legitimate CI users. Not proposed as a default, only as an opt-in. Block --dangerously-skip-permissions by default. Would break sandbox/devcontainer users. More invasive than needed. Documentation-only fix. Insufficient. The gap isn't that the existing mechanisms are weak — it's that users don't know they need to assemble them.

Smaller asks that would also help, independent of the above

Surface managed-settings in onboarding. A single line in claude /status or first-run output (e.g. "No enterprise managed settings configured — see docs/security for hardening recommendations") would dramatically increase adoption. Right now the file is invisible until you go looking for it. Document the -p trust-verification bypass in claude --help and in the headless docs (already tracked as #20253). The security implication is currently buried as a sub-bullet on the security page only. Add claude doctor --security. Audit the install against a checklist (managed-settings present, bypass-mode disabled, deny rules for common secret paths, etc.) and print a report. This would make hardening a five-minute task instead of a research project.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

Why this matters beyond the individual user Claude Code is increasingly being adopted in regulated environments — clinical software, financial services, defense. In those contexts, defending a tool's security posture to an internal review means being able to say "the secure configuration is the default" or at minimum "the secure configuration is one documented step away." Right now, the answer for Claude Code is "assemble three layers yourself, two of which aren't mentioned in onboarding." That's a harder conversation than it should be, and a real friction point for adoption in environments where these tools could otherwise do a lot of good.

Additional Context

No response