claude-code - 💡(How to fix) Fix [FEATURE] Feature request: policy-driven permission mode for Pro/Max (safety gap) [1 participants]

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

Subject: Permission-mode tier gating on Pro/Max creates a safety regression and regulatory exposure

This is product feedback, not a bug or a support request. I'm a Max-tier individual customer using Claude
Code for real work at roughly $200 a month, and I want to raise a problem with how permission modes are
segmented between Pro/Max and Enterprise that I don't think the current tier design is pricing in correctly.

Individual Pro/Max users effectively have three permission states: default (prompt on every tool use),
acceptEdits (auto-approve edits only), and bypassPermissions / --dangerously-skip-permissions (run everything without checking). The middle ground, meaning configurable auto-approve with policy-driven
defaults and granular allow/deny controls, exists in the Enterprise configuration surface but is not exposed to paying individual customers.

This forces high-usage power users to pick between constant interruption that breaks flow on every tool
call, or bypass mode, which is explicitly the least safe state the tool supports and which Anthropic's own warnings flag as dangerous. There is no middle state available for individual paying users, despite the
middle state being exactly what an experienced power user wants.

This is a safety regression, not just a feature gap. Anthropic's public brand is safety-focused AI. Gating
the intermediate safety configurations pushes individual high-frustration users toward the bypass mode you yourselves warn against. The tier split inverts the expected safety ordering: Enterprise customers get safer defaults while individual paying customers are pushed toward the most permissive and least-audited mode.

This is not hypothetical. One individual power user running --dangerously-skip-permissions because the
alternative was untenable, and then leaking credentials, corrupting work, or triggering unintended external side effects, is a predictable outcome of the current design. It is exactly the category of incident that
becomes a blog post, a Hacker News thread, or a press article, and the story writes itself: Anthropic gated the safe mode behind enterprise pricing, so users flipped the dangerous switch.

On the regulatory side, the political environment around AI is not distant or abstract. The EU AI Act is in force. California has passed and is passing AI-specific consumer protection legislation. FTC is scrutinizing AI consumer practices. The pattern of safety-adjacent features gated behind enterprise tiers while
individual consumers receive a worse and riskier product maps directly onto the arguments currently driving AI legislation: arguments about models trained on broad public and creative output being captured behind paywalls that disproportionately benefit corporate customers.

Anthropic operates under an implicit political license that depends on being seen as a company that treats
individual users seriously rather than as a revenue afterthought next to the enterprise motion. That license is a real asset. It erodes in small increments product teams do not always measure, and the permission-mode tier split is one of those increments. It is a small, visible data point that works against the brand position the company is trying to defend.

Pricing segmentation between consumer and enterprise tiers is standard SaaS practice and I am not arguing
against it in general. The specific issue is that safety-adjacent configuration should not be on the enterprise-only side of the line, even when other features legitimately are. Pricing segmentation is normal. Safety segmentation creates direct brand and regulatory risk that ordinary feature gating does not.

What I am actually asking for: configurable allow and deny lists for tool use on Pro and Max tiers; a
policy-driven intermediate permission mode between acceptEdits and bypassPermissions, effectively a settings file that specifies which tool calls auto-run, which require approval, and which are forbidden, without
requiring an enterprise contract; and explicit acknowledgement that safety-adjacent configuration is not a standard feature-gating candidate, even when other enterprise capabilities legitimately are.

Please do not treat this as a support ticket or route it to sales. The specific product ask is secondary.
The primary point is that the current design creates a measurable safety and regulatory exposure that the individual feature decision does not reflect, and the fix is small compared to the downside it prevents.

Dan Max-tier customer

Proposed Solution

What I am actually asking for: configurable allow and deny lists for tool use on Pro and Max tiers; a
policy-driven intermediate permission mode between acceptEdits and bypassPermissions, effectively a settings file that specifies which tool calls auto-run, which require approval, and which are forbidden, without
requiring an enterprise contract; and explicit acknowledgement that safety-adjacent configuration is not a standard feature-gating candidate, even when other enterprise capabilities legitimately are.

Alternative Solutions

No response

Priority

High - Significant impact on productivity

Feature Category

Developer tools/SDK

Use Case Example

I am working on a project to 4 projects concurrently I do not want to hit approve every 30 seconds to a minute and have to hop between windows to do it. The only option available is to disable permissions.

Additional Context

No response