fix(tool-config): respect question permission from OPENCODE_CONFIG_CONTENT

[Chocothin]

Summary

applyToolConfig() ignores the question: "deny" permission already set via OPENCODE_CONFIG_CONTENT and unconditionally overrides it based solely on the plugin-internal OPENCODE_CLI_RUN_MODE variable. This causes agents to hang indefinitely in headless environments (e.g., Maestro Auto Run) where the host correctly sets question: "deny" but has no knowledge of the plugin-internal env var.

Root Cause

The current logic in tool-config-handler.ts:

const isCliRunMode = process.env.OPENCODE_CLI_RUN_MODE === "true";
const questionPermission = isCliRunMode ? "deny" : "allow";

This only checks OPENCODE_CLI_RUN_MODE (set exclusively by oh-my-opencode's own run() function in src/cli/run/runner.ts). Any external caller that sets question: "deny" via the standard OPENCODE_CONFIG_CONTENT env var gets silently overridden to "allow", causing the question tool to block on stdin in headless mode.

Causal chain:

1. Host (e.g. Maestro) spawns OpenCode with OPENCODE_CONFIG_CONTENT='{"permission":{"question":"deny"}}'
2. OpenCode reads config → question: "deny" ✅
3. oh-my-opencode plugin's applyToolConfig() runs
4. OPENCODE_CLI_RUN_MODE is not set (host doesn't know about it) → questionPermission = "allow"
5. Sisyphus, Hephaestus, Prometheus get question: "allow" → overrides the host's deny
6. Question tool activates → waits for stdin → hang

Fix

Read permission.question from OPENCODE_CONFIG_CONTENT and give it highest priority:

config explicit deny  →  deny   (respects host/caller intent)
CLI run mode          →  deny   (existing behavior preserved)
default               →  allow  (interactive mode, unchanged)

Changes

• src/plugin-handlers/tool-config-handler.ts: Added getConfigQuestionPermission() helper that reads OPENCODE_CONFIG_CONTENT env var. Updated questionPermission to check config deny first.
• src/plugin-handlers/tool-config-handler.test.ts: Added 12 tests covering 4 scenarios × 3 agents (sisyphus, hephaestus, prometheus), with proper env var save/restore.

Test Results

bun test v1.3.6
 23 pass
 0 fail
 34 expect() calls
Ran 23 tests across 1 file. [21.00ms]

Context

• Related: Question tool not available despite being configured #730 (question tool fix that introduced the hard-coded "allow")
• Related: [Feature]: Native QuestionTool not available when oh-my-opencode plugin is active #934 (duplicate of Question tool not available despite being configured #730)
• External: RunMaestro/Maestro#338 — the downstream issue this fixes

---

Summary by cubic

Respect OPENCODE_CONFIG_CONTENT.permission.question in applyToolConfig to avoid overriding host settings. This prevents headless hangs (e.g., Maestro Auto Run) by not forcing question: allow.

• Bug Fixes
  • Priority: config deny → deny; CLI run mode (true) → deny; default → allow.
  • Added getConfigQuestionPermission and tests covering agents and env var scenarios.

^{Written for commit 65bc742. Summary will update on new commits.}

[github-actions]

All contributors have signed the CLA. Thank you! ✅
_{Posted by the CLA Assistant Lite bot.}

[Chocothin]

I have read the CLA Document and I hereby sign the CLA

[code-yeongyu]

[sisyphus-bot]

PR Review: Bugfix Verified ✅

Bug Analysis:
This is a legitimate bug. The original code unconditionally set questionPermission based solely on the internal OPENCODE_CLI_RUN_MODE env var, completely ignoring OPENCODE_CONFIG_CONTENT.permission.question. This breaks headless environments where the host correctly sets question: "deny" but doesn't know about the plugin-internal variable.

Root Cause (lines 34-35 in original):

const isCliRunMode = process.env.OPENCODE_CLI_RUN_MODE === "true";
const questionPermission = isCliRunMode ? "deny" : "allow"; // Ignores config!

Fix Verification:
The new logic correctly prioritizes:

1. Config explicit deny → deny (respects host intent)
2. CLI run mode true → deny (preserves existing behavior)
3. Default → allow (interactive mode unchanged)

Code Quality:

• 12 new test cases covering 4 scenarios × 3 agents (sisyphus, hephaestus, prometheus)
• Proper env var save/restore with beforeEach/afterEach
• Clean implementation of getConfigQuestionPermission() helper
• Given/when/then test structure follows project conventions

CI Status: 2/3 passing (CLA ✅, GitGuardian ✅, cubic AI reviewer still running)

Merge Conditions:

• ❌ NOT APPROVED - Missing maintainer review
• ✅ CI passing (non-blocking check still running)
• ✅ No conflicts (mergeable)
• ✅ Safe bugfix with no side effects

Recommendation: Ready for approval and merge once reviewed. This fixes a real production issue in headless environments.

[Chocothin]

@cubic-dev-ai

[cubic-dev-ai]

@cubic-dev-ai

@Chocothin I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Auto-approved: The change correctly prioritizes explicit 'deny' from config to fix headless hangs while preserving existing CLI behavior, backed by comprehensive tests.}