Feature Request: Add YOLO mode (bypassPermissions) to Shift+Tab permission mode cycle

Status Fixed / completed
Maintainer reply None cached
Activity 12 comments · opened Dec 31, 2025 · closed Aug 17, 2026

Summary

Currently, pressing Shift+Tab cycles between three permission modes:

  • Normal mode
  • Plan mode
  • Auto-accept edits mode

I'd like to have bypassPermissions (YOLO mode) added as an option in this Shift+Tab cycle.

Use Case

As a developer, I often have different working scenarios:

  1. Busy / AFK: When I'm away from my computer or busy with other tasks (video editing, meetings, etc.), I want Claude to run autonomously without waiting for my approval on each action.
  1. Available / Monitoring: When I have time to watch the terminal, I want to review and approve each action manually.

Currently, switching between these modes requires restarting Claude Code entirely, which:

  • Loses the current conversation context (unless using --resume)
  • Interrupts the workflow
  • Is inconvenient for frequent switching

Proposed Solution

Add bypassPermissions (YOLO mode) to the Shift+Tab cycle:

Normal → Plan → Auto-accept edits → YOLO mode → Normal ...

Or provide a keyboard shortcut / slash command to toggle YOLO mode within an active session.

Alternative Solutions Considered

  1. Shell aliases (yolo / safe) - Only work when starting a new session, not within an active session
  2. Modifying settings.json - Changes don't take effect until restart
  3. MCP/Hooks/Skills - Cannot modify core permission settings at runtime

Additional Context

I understand YOLO mode has security implications. Perhaps it could:

  • Require an additional confirmation when enabling via Shift+Tab
  • Show a prominent visual indicator when YOLO mode is active
  • Have a timeout option (auto-revert to normal mode after X minutes)

Thank you for considering this feature!

View original on GitHub ↗

10 Comments

github-actions[bot] · 8 months ago

Found 1 possible duplicate issue:

  1. https://github.com/anthropics/claude-code/issues/6265

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

FrostKiwi · 8 months ago

Because of reports like this: https://old.reddit.com/r/ClaudeAI/comments/1pgxckk/claude_cli_deleted_my_entire_home_directory_wiped/ I'd say suggest it remain the launch parameter --dangerously-skip-permissions to ensure there is a no-chance-of-misunderstanding "user consent" step and not something you may accidentally enable by having a key combo register twice.

midlifedad · 7 months ago

+1 for adding dontAsk mode to the Shift+Tab cycle.

Use case: I'm running a multi-agent workspace (12 Claude Code instances in tmux panes) where agents work autonomously on assigned projects. Each agent has configured permissions via settings.json:

{
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": ["Bash(git *)", "Bash(npm *)", "Edit(**)", ...],
    "ask": ["Bash(git push *)"],
    "deny": ["Bash(rm -rf /)", "Bash(sudo *)"]
  }
}

This gives me fine-grained control: common operations auto-approve, dangerous commands are blocked, and specific commands (like git push) always prompt for human review.

The problem: If I accidentally press Shift+Tab while checking on an agent, they drop out of dontAsk mode and there's no way to get back without restarting Claude Code. The current cycle (Default → Accept Edits → Plan) doesn't include dontAsk.

Why this makes sense:

  • dontAsk respects the configured allow/deny lists - it's not bypassing security, it's using the configured security
  • It's already trusted enough to be the startup default, so it should be toggleable during a session
  • The current behavior forces a full restart just to restore the configured permission mode
  • For multi-agent setups, restarting means losing context and interrupting work

dontAsk is fundamentally different from bypassPermissions - it enforces the configured rules rather than ignoring them. Adding it to the Shift+Tab cycle would make the permission system much more usable for workflows that rely on pre-configured permissions.

DrAlexHarrison · 7 months ago

Clauding dontask mode as I write this. If real, will use. Thank you! +1 for yolo.

1kko · 7 months ago

+1 for @midlifedad, this will generally allow power users to modify on their own, while protecting entry levels.

hikidd · 6 months ago

I love YOLO mode—it’s really handy in the Gemini CLI, but Claude doesn’t have it. That’s a bummer.

giglsmith · 5 months ago

Claude Code Mode Switching Workaround
Starting Claude Code with the --dangerously-skip-permissions flag at startup enables full mode cycling via Shift+Tab mid-session, allowing you to switch between Normal, Auto-Accept, Plan, and Bypass modes as expected. Without this flag, Shift+Tab only cycles through the first three modes and bypass is inaccessible during a session. Note that the session starts in bypass mode, so switch to your preferred mode immediately after launch.

joaovcoliveira · 5 months ago

Until this ships, npx claude-trust-me-bro enable gives you persistent YOLO without the --dangerously-skip-permissions flag — uses hooks + allow rules so you don't lose session context. tmb disable to go back to normal. https://github.com/joaovcoliveira/claude-trust-me-bro (author here)

Mr-Wallet · 4 months ago

I would also like to see dontAsk added to the cycle (and this is the only open issue that seems to have any mention of it at all). Sometimes I want the AI to avoid doing something dumb and try to figure out how to do it with only approved tools so it doesn't get completely stuck on a permissions prompt until I come check it.

stefmf · 4 months ago

+1 — This would be very useful. Starting a session without --dangerously-skip-permissions and then needing to toggle it on mid-conversation currently requires a full restart. A slash command like /dsp or adding it to the Shift+Tab cycle would save a lot of friction.

Showing cached comments. Read the full discussion on GitHub ↗