Permission system is completely non-functional: no tool ever prompts, equivalent to permanent --dangerously-skip-permissions (v2.1.197)

Description

Claude Code's permission system does not function at all on this machine. No tool call — Bash, Edit, Write, or MCP tools — ever produces a permission prompt, regardless of whether the command/action matches an allowlist rule. This is effectively identical to always running with --dangerously-skip-permissions, except that flag was never passed and /permissions reports the session is in default/interactive mode. This makes Claude Code unusable for anyone relying on permission gating as a safety boundary.

Version

2.1.197

Steps to reproduce

1. In a project with a .claude/settings.json / settings.local.json that only allowlists specific narrow command patterns (e.g. Bash(go:*), Bash(git status*)) and does not include a wildcard Bash(*) rule or any blanket tool allow.
2. Confirm permission mode is default/interactive via /permissions.
3. Ask Claude Code to run any tool call that isn't covered by an allowlist rule — e.g. whoami, curl -sI https://example.com, a novel destructive command like rm -rf /tmp/some-throwaway-path with the Bash tool's dangerouslyDisableSandbox set to true, or any other tool (Edit, Write, MCP tool calls, etc.).

Expected behavior

A permission prompt should appear asking the user to approve/deny the tool call, since none of these match an allowlist rule and the mode is not bypass.

Actual behavior

Every tool call runs immediately with no prompt whatsoever. This was verified across Bash (safe read-only, network, and destructive-with-sandbox-disabled commands) and holds for every other tool type available in the session — there is no tool we could find that triggers a permission prompt at all.

What we ruled out

• Terminal/wrapper app: Reproduces in a plain terminal invocation of claude directly, not just inside a third-party terminal wrapper (cmux) that also launches Claude Code sessions.
• Project/global settings: Neither .claude/settings.json nor ~/.claude/settings.json contain a bypass/wildcard allow rule or a defaultMode override.
• Per-project state in ~/.claude.json: The project entry has allowedTools: [] and no permissionMode/bypass flag stored.
• Shell aliasing: claude resolves directly to the real binary (/Users/quinn/.local/bin/claude) with no shell alias/function/env var injecting --dangerously-skip-permissions or --permission-mode.

Possible lead

~/.claude.json contains cached internal experiment state that may be relevant:

cachedGrowthBookFeatures.tengu_permission_friction = true
cachedGrowthBookFeatures.tengu_cfc_in_product_permissions = true
cachedGrowthBookFeatures.tengu_harbor_permissions = true
cachedStatsigGates.tengu_disable_bypass_permissions_mode = false

These look like Statsig/GrowthBook-gated experiment flags related to permission-prompt behavior. It's possible an experiment on this account is stuck in a state that suppresses all prompts entirely.

Impact

Severe: this defeats the entire permission model. Any destructive, irreversible, or sensitive action (arbitrary shell commands, file writes anywhere on disk, network calls, MCP tool calls with side effects) executes without any user confirmation, with no way found so far to force a prompt.

Environment

• OS: macOS (Darwin 25.3.0)
• Claude Code version: 2.1.197
• CLAUDE_CODE_ENTRYPOINT=cli