Repository navigation
[FEATURE]: Permission "always" should be conversation-level, not OpenCode session-level #18023
Closed as not planned
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Problem Description
Currently, when a user approves a permission with the "always" option, it persists across all conversations within the same OpenCode session until OpenCode is restarted. This causes the following issues:
- Security Risk: When creating a new context/conversation, previously approved dangerous operations (like database writes, file deletions) are automatically allowed without re-confirmation
- Poor User Experience: Users expect "always" to mean "always in this conversation", not "always until I restart the app"
Current Behavior
According to the OpenCode documentation:
"always" - approve for the remainder of the current OpenCode session
This means:
- User approves
clickhouse_execute_writewith "always" in Conversation A - User creates Conversation B (new context)
clickhouse_execute_writeis automatically approved in Conversation B without confirmation- Only way to reset is to restart OpenCode entirely
Desired Behavior
The "always" permission approval should:
- Persist only within the current conversation/context
- Reset when creating a new conversation/context
- Not require restarting OpenCode to reset
Alternative Proposal
Add a new permission option:
once- approve only this single operation (existing)conversation- approve for the remainder of this conversation (new)session- approve for the remainder of this OpenCode session (existing "always" behavior)
Use Cases
- Development Workflow: Developer needs to approve database write operations in one conversation, but wants fresh approvals in the next conversation
- Multi-Task Scenarios: User switches between different tasks requiring different approval levels
- Security Consciousness: User wants to be extra careful when starting a new task/context
Workarounds
Currently, the only workaround is to:
- Always use "once" (tedious)
- Restart OpenCode frequently (disruptive)
Impact
This change would:
- Improve security by ensuring fresh approvals for new contexts
- Better match user expectations
- Reduce accidental approvals
- Maintain flexibility for users who want session-level persistence (if using the "session" option)
References
- Documentation: https://opencode.ai/docs/zh-cn/permissions/
- Related to conversation/context isolation features
Reacted by Sergey Kostrukov, Dan Dascalescu, Alexander Paramonov, Volker Jaenisch (PhD), Kai Yang and Fyam
Reacted by Ariane Emory and Chaz Reid
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Mar 18, 2026
This issue might be a duplicate of existing issues. Please check:
Please review those issues to see if your request is already covered or if you can contribute to the existing discussion there.
ariane-emory commentedon Mar 18, 2026
Explanation/description could be better: the way that the words "session" and "conversation" are used here leave me completely unclear on what the issue is here.
AlexParamonov commentedon Mar 18, 2026
This is a huge bloker to switch to opencode as main harness. As this bug of
session wide allowjust forces you to never use it for interractive session and approve all edits manually, even if you are happy with this particular file edits or this one batch.additionally, if i want to approve edit manually, i want to see entire edit, not just the top part. Now i have to yet another key combination just to read it.
I belive ability to toggle
allow-edit, full edit view by default, plus editing with external editor are must for interractive harness workflow.ariane-emory commentedon Mar 19, 2026
@AlexParamonov I think you're going to explain just what you mean by "conversation" in order for us to understand what the issue is. "Conversation" is not part of the usual terminology used to describe the program's behaviour, and so it's meaning here isn't at all clear to me.
AlexParamonov commentedon Mar 19, 2026
@ariane-emory I believe the term was introduced by @swpuchenxinde
From my point of view, I just need a way to withdraw my permission to edit. Consider how it is done in Claude Code, for example: at any time, the user can change the permission level from 'allow edits' to 'yolo' to 'plan' to 'default'. What is missing in OpenCode for me is that, when I have an interactive session and the harness asks for permission to edit a file, once I give it permission for everything, I can't revoke it for the next question.
So, commands like /edit and /no-edit would suffice for manual control. Alternatively, there could be another option to "accept edits until next message". This would mean that the agent could finish all edits in this loop until the user sends another message.
Let me know if this makes sense to you.
github-actions commentedon Jul 3, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
kfstorm commentedon Jul 5, 2026
I think this is especially important for OpenCode Web.
In the CLI, an “OpenCode session” may feel relatively short-lived. But in OpenCode Web, the backend/web process can stay alive and serve multiple conversations over time. In that model,
alwayseffectively becomes broader than users may expect: a permission granted in one conversation can silently carry over to later, unrelated conversations.That is the main security concern for me. When starting a new conversation in OpenCode Web, I would expect risky permissions to be reset unless I explicitly chose a wider scope.
Maybe the permission choices should distinguish:
onceconversationsessionThis would keep the current session-wide behavior available, while making the safer OpenCode Web default possible.