Skip to content

[BUG] --dangerously-skip-permissions ignores --permission-mode flag #17544

Closed as not planned

Description

@knowsuchagency

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

Note: This issue was previously reported as a feature request in #11401, but it is actually a bug/regression in behavior.

What's Wrong?

When using --permission-mode plan --dangerously-skip-permissions together, the --dangerously-skip-permissions flag causes Claude to completely ignore the --permission-mode setting. Instead of starting in plan mode with permissions bypassed, it starts in bypass permissions mode.

The alternative flag --allow-dangerously-skip-permissions does respect the permission mode, but it prompts the user to trust the directory when launched. This is tedious and not what users expect when explicitly passing that flag.

What Should Happen?

  • claude --permission-mode plan --dangerously-skip-permissions should start in plan mode with permissions bypassed (no prompts for read-only operations)
  • The two flags should be composable: --permission-mode controls which mode to start in, --dangerously-skip-permissions controls whether to bypass permission prompts
  • --allow-dangerously-skip-permissions should not prompt to trust the directory when used with an explicit --permission-mode

Steps to Reproduce

  1. Run claude --permission-mode plan --dangerously-skip-permissions
  2. Observe that Claude starts in bypass permissions mode, not plan mode
  3. The --permission-mode plan flag is silently ignored

Alternative reproduction:

  1. Run claude --permission-mode plan --allow-dangerously-skip-permissions
  2. Claude prompts to trust the directory before starting
  3. Previously this would drop directly into plan mode without prompting

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown - but multiple users have confirmed this worked previously with --allow-dangerously-skip-permissions

Claude Code Version

2.1.4 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

See also: #11401 (mislabeled as feature request), #5466, #7136

Multiple users have confirmed this issue in #11401 and are actively requesting a fix.

Activity

  1. github-actions commented on Jan 11, 2026

    @github-actions

    Found 2 possible duplicate issues:

    1. Should plan mode enforce read-only restrictions when using --dangerously-skip-permissions? #17021
    2. [BUG] --fork-session flag ignored when using --resume with TUI session picker #15694

    This issue will be automatically closed as a duplicate in 3 days.

    • If your issue is a duplicate, please close it and 👍 the existing issue instead
    • To prevent auto-closure, add a comment or 👎 this comment

    🤖 Generated with Claude Code

  2. nullbio commented on Jan 12, 2026

    @nullbio

    This is still an issue.

  3. coygeek commented on Jan 20, 2026

    @coygeek

    I use this workaround:

    claude --dangerously-skip-permissions "/plan"
    
  4. jamesanglin commented on Feb 9, 2026

    @jamesanglin

    This works for me.

    claude --allow-dangerously-skip-permissions --permission-mode plan

    As others have stated, it does prompt you to trust the directory; however, you only have to do that once per project. This is no big deal if you're working a lot in the same project, but I can see how it might get tedious for other use cases.

  5. github-actions commented on Mar 11, 2026

    @github-actions

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.

  6. github-actions commented on Mar 18, 2026

    @github-actions

    This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

  7. locked as resolved and limited conversation to collaborators on Mar 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:corebugSomething isn't workinghas reproHas detailed reproduction stepsplatform:linuxIssue specifically occurs on LinuxstaleIssue is inactive

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions