Feature Request: Yolo and non-Yolo mode (auto-accept)

Hi :)

Background:

Like in Claude-Code there are permissions in opencode:
"permission": {
"edit": "ask",
"bash": "ask",
"webfetch": "ask"
},

I use auto-accept/yolo/allow-permissions mode about 15% of the time.

Ask:
I would like to be able to switch between my default 'ask' permissions to yolo 'allow' all permissions. As easily as with something like tab.

Context:
In claude code there are 3 modes that can be cycled through using SHIFT+TAB:
Plan
Normal/Build with ask permissions
Normal/Build with auto-accept permissions (allow)

That difference between the two Normal/Build modes is what I'm looking for.

I would actually much prefer this to pressing a and then being stuck in auto-accept mode without a way to go back to ask-mode. I was considering filling a seperate issue for supporting always-ask, but I think this feature might solve my underlying issue of not being able to switch back to ask mode just as well.

In the next release plan mode is going to have more tool access and all of them (bash, edit) are going to be ask by default, I think this will address what OP brought up, would this work for u too?

I helped myself, by creating a custom autoaccept agent for this functionality.

Here is my config (I omitted unrelated details):

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "edit": "ask",
    "bash": {
      "ls": "allow",
      "pwd": "allow",
      "git status": "allow",
      "git diff*": "allow",
      "git add*": "allow",
      "git log*": "allow"
    }
  },
  "agent": {
    "plan": {
      "mode": "primary",
      "tools": {
        "write": false,
        "edit": false,
        "bash": true
      }
    },
    "build": {
      "mode": "primary",
      "tools": {
        "write": true,
        "edit": true,
        "bash": true
      }
    },
    "autoaccept": {
      "mode": "primary",
      "tools": {
        "write": true,
        "edit": true,
        "bash": true
      },
      "permission": {
        "edit": "allow"
      }
    }
  }
}

But if I understand it correctly, this way the build agent "reminder" won't be added. It would be nice if there would be an option to configure custom reminders for agents.

In the next release plan mode is going to have more tool access and all of them (bash, edit) are going to be ask by default, I think this will address what OP brought up, would this work for u too?

Hi,
No, not fully.
I use all modes in Claude-Code, and they are all useful. I don't feel like anything is missing.

Modes and use cases:

Plan:
I never want edit suggestions, just explore and plan. I use the better Opus 4.1 model for complex problems that I have mostly figured out.
Usage: ~30% of the time

Normal:
Chatting, like on the Claude website.
I explore, ask questions, and make small changes. The key difference is that I don't have anything figured out yet. I just want quick feedback to figure things out. That's why I prefer a cheaper model (sonnet-4) with less intensive thinking. Once I have things figured out and know what I want to do, I validate it with Plan mode and create a plan for making the changes.
Usage: ~50% of the time

Auto-accept/Yolo:
For prototyping scripts or tasks I don't want or need to fully understand.
I use it to make straightforward, low-risk changes without confirmation and to create debug-scripts for debugging application parts.
Usage: ~20% of the time

claude code plan behaves basically same to what I outlined above, you can always edit the build/plan modes to be more aligned with your specific workflow, you can also add custom agents that you can also tab through if you prefer something more custom

What's really cool about Claude Code is that it distinguishes not on the binary but on the secondary level. Like, doesn't propose you to always accept git:* commands, but proposes to always accept git log:* instead. It makes much more sense and allows quick teaching the agent to properly and effectively behave.

Because of that, even with no yolo mode enabled, Claude Code almost never bothers me with acceptance requests, which I find very nice in comparison with opencode.

Could this also be done for opencode?

I think I get what you are saying, yeah we probably can do that

sounds like better ux

@amal

@amal this should be fixed on latest ex:

 "permission": {
    "bash": {
      "git *": "ask"
    }
  }

if llm runs "git log -n 10" and I allow always, then it tries to run "git diff", it will still prompt for "git diff"

Permissions should behave as expected now and when you do an accept always for bash commands it tries to find the nearest subcommand rather than approving "git *"

(works for other commands besides git ones but just using it as example)

@rekram1-node

@rekram1-node thank you so much! ❤️

~~Can we please also get this type of step-by-step learning, when the opencode could propose to always allow e.g., git fetch * instead of git * by default?~~

Upd: it seems like it already should behave like that! I will give it a try!

I've been exploring the yolo mode implementation for a few days and have run into some interesting behaviour that's worth sharing.

Here's a summary of my key observations:

For yolo mode to be truly effective, permissions need to propagate through delegations. The current behaviour seems to restrict delegated agents, even when the primary agent has full access.
I attempted to create a dedicated 'yolo-only' sub-agent (yolo:sub-agent) and delegate to it from the primary yolo agent. This approach caused a cascade of failures, so it's not a viable path. The only way I could get something similar to work was by mimicking the internal prompt logic, and injecting a new reminder, which feels like a hack and isn't scalable.
The primary issue is that this internal-based approach bypasses the specialised sub-agents entirely, which defeats the purpose of the agent system.

I think the best path forward would be to implement a permission propagation system specifically for yolo mode. This system would ensure that an agent's permissions are passed down through the delegation chain.

I'm keen to see yolo mode fully implemented, but I recognise that this change could introduce significant complexity to the opencode internals. If not designed carefully, it could lead to an influx of permission-related issues. Perhaps we can discuss the design trade-offs and find a robust way to implement this functionality.

are you specifically talking about subagents being called and having to approve their actions?

are you specifically talking about subagents being called and having to approve their actions?

Yes. They do not inherit the primary agent's permissions, do they?

correct, but you can override this or if you are making custom ones you can give them free reign

@arsham

@arsham have you tried making an agent like this?

---
description: <your description>
permission:
  edit: "allow"
  bash: "allow"
  webfetch: "allow"
---

<your prompt>

This will never ask for permissions, isn't that the goal?

@rekram1-node

@rekram1-node yes I have. My concern is that I have quite a few agents with specific sets of permission allowed, and the rest set to "ask". I want them to ask for permission for performing a certain task such as edit. The issue is reusing the same agent in a scenario that I could let the primary orchestrate in yolo mode.

I am still not sure if I wanted to set the agents go about whatever they need to do. Of course I am using git worktrees, but that wouldn't be helpful in majority of situations.

Hm I don't think I am following what your ask was then

My apologies for the confusion; let me try to clarify.

I have an existing set of agents that are designed with specific restrictions, meaning they're configured to ask for permission for certain actions in Plan and Build modes. For example, I've set them to prompt for approval before staging new files to a commit. This is a deliberate choice to give me granular control and prevent them from making changes I haven't explicitly approved.

My goal is to be able to use this exact same set of agents in Yolo mode. I want to create a new primary agent that, when activated, essentially overrides the sub-agents' default permissions and grants them full access. This way, I can leverage the existing agent configurations for fine-grained control when I need it, but also quickly switch to a fully automated Yolo mode without having to duplicate or modify all the underlying agent definitions.

Ahhh okay that makes sense I understand now thank you

Yeah I don't think that is possible currently (without editing the agents ofc) but interesting idea

Hey guys I just noticed this issue, its similar to what I proposed to contribute.

The proposed updates the "PLAN" mode from "Read-Only" to "Approving Changes" mode similar to Claude Code.

Problem: when users asked to draft a plan and write to root, it would fail, explain why with long text, and suggest switching to build mode. That many times ran unwanted changes without asking the user for further permission.

Solution: similar to Claude code; now, it always asks for user approval before making any changes, fixing the issue and making things safer and easier to use.

Hey guys I just noticed this issue, its similar to what I proposed to contribute.

The proposed updates the "PLAN" mode from "Read-Only" to "Approving Changes" mode similar to Claude Code.

Problem: when users asked to draft a plan and write to root, it would fail, explain why with long text, and suggest switching to build mode. That many times ran unwanted changes without asking the user for further permission.

Solution: similar to Claude code; now, it always asks for user approval before making any changes, fixing the issue and making things safer and easier to use.

The above proposed feature improved UX drastically to my use-case at least, it gets pretty similar to Claude code on this aspect. For me I like to work with the AI not letting it YOLO. So accepting changes has allowed me to take control.

The UX is great with approving changes, super fast too. For me works smooth and as I need. Four changes approved in 17s meanwhile Claude would still be thinking for the first execution 😆; it's like heaven on earth bros 😅

Thank you OpenCode team for this amazing tool!

opencode-approving-changes-with-edit-tool-demo.mp4

YOLO mode has been implemented in PR #9073!

What's included:

✅ Switch between 'ask' and 'allow' (YOLO) modes
✅ Desktop: Settings → Danger Zone with one-click toggle
✅ CLI: opencode yolo enable/disable/status commands
✅ CLI flag: opencode --yolo
✅ Env var: OPENCODE_YOLO=true
✅ Config: "yolo": true in opencode.json

Two toggle options:

Session-only: Resets when you restart OpenCode
Permanent: Saves to config, persists across restarts

The Shift+Tab cycling like Claude Code is not included in this PR but could be added as a follow-up enhancement.

codex --yolo ez. opencode? press accept 2 times and again and again...
The last message from mguttmann leads to a vibeslop chaos of PRs

Can this issue be picked up?
I find it weird that there's no way, via args or /command to set auto-accept permissions.
Literally every other CLI has this.

codex --yolo ez. opencode? press accept 2 times and again and again... The last message from mguttmann leads to a vibeslop chaos of PRs

Can this issue be picked up? I find it weird that there's no way, via args or /command to set auto-accept permissions. Literally every other CLI has this.

They are busy roasting claude code right now.

To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.

Navigation Menu

Repository navigation

Feature Request: Yolo and non-Yolo mode (auto-accept) #1813

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature Request: Yolo and non-Yolo mode (auto-accept) #1813

Description

Activity

adamcik commented on Aug 22, 2025

rekram1-node commented on Aug 22, 2025

tobias-walle commented on Aug 22, 2025

nordrune commented on Aug 22, 2025

rekram1-node commented on Aug 22, 2025

art-shen commented on Aug 30, 2025

rekram1-node commented on Aug 30, 2025

rekram1-node commented on Sep 16, 2025

art-shen commented on Sep 16, 2025

arsham commented on Sep 17, 2025

rekram1-node commented on Sep 17, 2025

arsham commented on Sep 17, 2025

rekram1-node commented on Sep 17, 2025

1 remaining item

rekram1-node commented on Sep 17, 2025

arsham commented on Sep 17, 2025

rekram1-node commented on Sep 17, 2025

arsham commented on Sep 17, 2025

rekram1-node commented on Sep 17, 2025

adolfousier commented on Oct 20, 2025

adolfousier commented on Oct 20, 2025

adolfousier commented on Oct 21, 2025

mguttmann commented on Jan 17, 2026

dlukt commented on Feb 6, 2026

keejkrej commented on Feb 6, 2026

github-actions commented on Apr 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions