fix: auto-deny permissions and emit events in non-interactive mode #6832
+225
−29
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Add isInteractive() utility to detect CI/non-TTY environments - Auto-deny permission requests when running non-interactively - Emit permission.asked events before denying for visibility - Subscribe to permission events in github.ts and run.ts with actionable guidance - Add OPENCODE_EMIT_SUBAGENT_EVENTS flag for verbose subagent output - Add emit_subagent_events input to GitHub Action
rekram1-node
reviewed
Jan 4, 2026
Comment on lines
+131
to
+139
| const info: Request = { | ||
| id, | ||
| ...request, | ||
| } | ||
|
|
||
| // Non-interactive mode: no one to approve, auto-deny | ||
| if (!isInteractive()) { | ||
| Bus.publish(Event.Asked, info) | ||
| log.warn("auto-denied permission in non-interactive mode", { |
Collaborator
There was a problem hiding this comment.
Im not sure this is the correct approach, wouldnt this fail for desktop app and other clients?
Contributor
Author
There was a problem hiding this comment.
good call - are there stable ways to detect desktop app? Other clients? Or TUI / terminal client?
any/all of these we can use to make sure we are operating in a terminal-only env.
(CI=true is easy but getting TTY state may fail)
Contributor
Author
There was a problem hiding this comment.
@rekram1-node - OK, after some investigation, updated the PR:
- this ONLY applies when
OPENCODE_CLIENTis set tocli - thus, other clients, such as
desktoptoday or any future client enum, won't be impacted - this should guard against cases where this would interfere with non-CLI clients
GUI clients like the desktop app handle permissions through their own UI, so we should not auto-deny when OPENCODE_CLIENT is set to something other than 'cli'.
Combined both changes: - Keep permission config from dev (deny question prompts in GitHub context) - Keep unsubscribeEvents return value from PR branch (for proper cleanup)
Contributor
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
- Fix unsubscribeEvents shadowing bug in github.ts (cleanup was never called) - Make CI env var check case-insensitive (CI=TRUE now works) - Use bracket notation for env var access (codebase consistency) - Add unit tests for isInteractive() covering all code paths
Keep both additions: - OPENCODE_EMIT_SUBAGENT_EVENTS from this PR - OPENCODE_SERVER_PASSWORD/USERNAME from dev
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes issues where permissions requests block indefinitely in CI/GitHub Actions, with no output indicating why. I keep running into this in CI runs, especially when the harness is trying to solve a problem or I'm testing/building plugins.
Since there's no way to prompt a user, it should just auto-deny by default + emit this to the logs so users can understand what happened.
Changes
isInteractive()utility - checksCIenv var,OPENCODE_CLIENT, and TTY state!isInteractive()(no one to approve)permission.askedevents before denying so they're visible in logsgithub.tsandrun.tswith actionable guidance on how to allowOPENCODE_EMIT_SUBAGENT_EVENTSflag for verbose subagent output in CIemit_subagent_eventsinput to GitHub Actionquestionpermission by default in GitHub Action sessions (merged from dev)isInteractive()LogicOnly auto-denies for the CLI client in non-TTY/CI environments:
OPENCODE_FORCE_INTERACTIVE=true→ interactive (for tests)CI=true→ non-interactive (auto-deny)OPENCODE_CLIENTis notcli(e.g.desktop) → interactive (GUI handles permissions)stdin.isTTY && stdout.isTTYcurrent possible
OPENCODE_CLIENTvalues:cli(default),desktopExample Output
When a permission is denied in CI:
Merge Conflict Resolution
Resolved conflict with
devbranch - combined:questionprompts in GitHub Action context)