You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Problem
When using OpenCode for automated workflows or in trusted environments, permission prompts can interrupt the flow and require manual intervention. This is particularly frustrating when you trust the agent and want it to operate autonomously.
Proposed Solution
This is already kinda possible with permissions env variable, but I feel like dedicated flag is nice because:
It matches Claude Code
It allows to show a warning in the UI that you are in YOLO mode
Usage
# CLI flag
opencode --dangerously-skip-permissions
# Environment variable
OPENCODE_DANGEROUSLY_SKIP_PERMISSIONS=true opencode
# With run command
opencode run --dangerously-skip-permissions "do something"
Behavior
Auto-allows all ask permission prompts
Explicit deny rules are still respected
Shows "△ YOLO mode" warning in the TUI (home screen, footer, and sidebar) to indicate the mode is active
Why This Belongs in OpenCode
This feature improves the developer experience for trusted workflows while maintaining safety through:
Clear naming that indicates danger (dangerously-skip-permissions)
Visual warnings when active
Respect for explicit deny rules
Similar to Claude Code's implementation, which users find valuable
you can just set your permissions to below, this overrides everything. has to be the opencode.json in the repo because its takes priority, not the the global config,
{
"permission": {
"*": {
"*": "allow",
}
}
}
Reacted by Faisal Alkheraiji, Peter Cunha, Sergey Tolmachev, kokayi, Wu Fei, SSpirits, Pride Chung, Marcel Gongora, seanmamasde, anik7afk and 14 more
Reacted by AbortRetryIgnore, xhd2015, Awesome-Kirill, Zhaoxiong Ding, Lucas-Rodrigues and mromanuk
Reacted by Sankalp Mukim, pythoninthegrass, Arkadii Emelianov, ACAne and mykola2312
Reacted by David Nix, Emanuel Aguirre, Fuwn, Markku Myllärinen, Bob Liu, Pietro Bondioli, Muthukumaran Navaneethakrishnan, Denis Fetinin, Filip Gara, Leon Si and 22 more
Sure, that could be another way, however, it just another hacky workarounds like the previous suggestions. In this use case, the drawback of switching agents is the loss of context, not all, but some of it.
I still think a better solution would be a runtime toggle within the active session. This would allow you to maintain continuity while temporarily enabling autonomous execution.
Reacted by Nikita Bilous, artemiyatcohere, Xuan Nguyen, Alex Chapin, Chaz Reid, Matthew Watt, AbortRetryIgnore, Jordan Castillo and dnl-rcd
This problem has already been solved in pretty much every other cli client, why is opencode making it hard? It should be SHIFT+TAB: YOLO ON/OFF. You shouldn't have to edit a config file or restart the app for this basic feature, and you should be able to turn it off the same way.
Reacted by Artem Timofeev, Jonah Schulte, CodeNebula and Michael Mortensen
this is stupid enough to move me to Pi. all this time and there are dozens of pull requests for this feature and the opencode team basically spits in our faces......
still no yolo, still no dangerously accept permissions.....
Are you guys trying to push us out?
Reacted by zc402, Daniel Rodriguez, Juan Villa, Michael Mortensen and Haydon Ryan
This was added in 1.17.12, you can run opencode --yolo, you can also ctrl+p within the tui and search for "permissions" there is a Disable/Enable auto-approve permissions option
Problem with this, there is no config (opencode.json) or env var to disable this?
We use opencode in our enterprise setting and we have no way to not allow yolo mode in control + p settings. any chance we can get an option here?
There is real demand for unattended mode, but a single flag should not collapse all permissions into “anything the OS account can do.” A safer contract is autonomous-by-default for read and reversible workspace edits, with a non-overridable floor for destructive filesystem, Git, database, cloud, and credential-bearing operations.
The UI warning is useful but insufficient after the session starts. Make the effective mode visible, require explicit opt-in, support scoped paths/credentials, and keep an audit trail of actions that were auto-approved versus hard-blocked.
Disclosure: I maintain gate.cat, an open-source pre-execution veto layer. I am in favor of autonomy; the point is to decouple “do not interrupt me” from “may irreversibly destroy any reachable resource.”
Activity
github-actions commentedon Jan 14, 2026
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if your specific use case differs from these existing requests.
orangeswim commentedon Jan 16, 2026
you can just set your permissions to below, this overrides everything. has to be the opencode.json in the repo because its takes priority, not the the global config,
mguttmann commentedon Jan 17, 2026
This feature has been implemented in PR #9073!
The implementation includes:
--dangerously-skip-permissionsflag (aliased as--yolo)OPENCODE_DANGEROUSLY_SKIP_PERMISSIONS/OPENCODE_YOLOenv varopencode yolo status/enable/disable"yolo": trueAdditionally includes runtime toggle via Desktop UI and API, allowing live switching without restart.
msgongora commentedon Mar 12, 2026
I honestly much rather have the option to toggle YOLO within the session, without having to exit. gemini-cli Ctrl+Y or Shirt+Tab (auto-accept edits).
If you want to follow @orangeswim suggestion, here you have. Use responsibly.
fix(opencode): switch from YOLO env var to settings-based permission …
adam-paterson commentedon Apr 6, 2026
You can just create a minimal yolo agent config and use tab in the TUI to switch to it:
{ "$schema": "https://opencode.ai/config.json", "agent": { "yolo": { "description": "Dangerously skip permissions", "permission": { "*": { "*": "allow" } } } } }msgongora commentedon Apr 6, 2026
Sure, that could be another way, however, it just another hacky workarounds like the previous suggestions. In this use case, the drawback of switching agents is the loss of context, not all, but some of it.
I still think a better solution would be a runtime toggle within the active session. This would allow you to maintain continuity while temporarily enabling autonomous execution.
docs(opencode): flag --yolo as install-time only + warn at launch
fix(kiro_cli): honor --yolo and profile.model at launch (#201)
abort-retry-ignore commentedon May 9, 2026
This problem has already been solved in pretty much every other cli client, why is opencode making it hard? It should be SHIFT+TAB: YOLO ON/OFF. You shouldn't have to edit a config file or restart the app for this basic feature, and you should be able to turn it off the same way.
bergstar commentedon May 9, 2026
Why no YOLO ?
mauriciotellezdev commentedon May 11, 2026
this is stupid enough to move me to Pi. all this time and there are dozens of pull requests for this feature and the opencode team basically spits in our faces......
still no yolo, still no dangerously accept permissions.....
Are you guys trying to push us out?
10 remaining items
AsmanovLev commentedon Jun 14, 2026
https://npmx.dev/package/@frankhommers/opencode-yolo
for those who are looking
fix(broker): inject permission allow-all block into opencode.json (#1161
alvarofranz commentedon Jun 19, 2026
Opencode is great. Just found it. But bro why is this being ignored?
+1 to the
opencode --dangerously-skip-permissionsrequestdhyaneesh commentedon Jun 30, 2026
We need this please
bbartels commentedon Jun 30, 2026
#33279 Looks like it was added?
vendelieu commentedon Jul 1, 2026
still being ignored?
unkistudio commentedon Jul 2, 2026
This was added in 1.17.12, you can run opencode --yolo, you can also ctrl+p within the tui and search for "permissions" there is a Disable/Enable auto-approve permissions option
xhd2015 commentedon Jul 5, 2026
then close this issue,
opencode --yolo, confirmed working onv1.17.13ViktorWelbers commentedon Jul 7, 2026
Problem with this, there is no config (opencode.json) or env var to disable this?
We use opencode in our enterprise setting and we have no way to not allow yolo mode in control + p settings. any chance we can get an option here?
pedrofsn commentedon Jul 11, 2026
Up
BGMLAI commentedon Jul 13, 2026
There is real demand for unattended mode, but a single flag should not collapse all permissions into “anything the OS account can do.” A safer contract is autonomous-by-default for read and reversible workspace edits, with a non-overridable floor for destructive filesystem, Git, database, cloud, and credential-bearing operations.
The UI warning is useful but insufficient after the session starts. Make the effective mode visible, require explicit opt-in, support scoped paths/credentials, and keep an audit trail of actions that were auto-approved versus hard-blocked.
Disclosure: I maintain gate.cat, an open-source pre-execution veto layer. I am in favor of autonomy; the point is to decouple “do not interrupt me” from “may irreversibly destroy any reachable resource.”
DocMAX commentedon Jul 18, 2026
please add --yolo or -y flag!
rekram1-node commentedon Aug 4, 2026
--dangerously-skip-permissions
and
--auto
and
--yolo
all exist, we call the flag
autobut it respects these other common aliases