omc team: need robust auto-approval for TUI permission dialogs instead of hardcoded pattern matching

[pgagarinov]

Problem

When omc team spawns Claude workers in tmux panes, various TUI confirmation dialogs (bypass permissions, workspace trust, etc.) can block worker startup. The current approach of detecting and auto-dismissing these dialogs via hardcoded string matching in pane content (paneHasTrustPrompt, checking for specific text like "Bypass Permissions mode" + "No, exit") is fragile:

1. New dialogs break it — any new Claude Code confirmation dialog (security prompts, update notices, auth re-confirmation) will stall workers until someone adds another hardcoded pattern
2. Text changes break it — if Claude Code changes the dialog wording, the detection fails silently
3. Pane size sensitivity — small tmux panes cause dialogs to auto-select "No, exit" because the "Yes" option isn't visible, and detection heuristics may not fire in time
4. Growing maintenance burden — each new dialog type requires a new detection function, dismiss sequence, and test coverage

Current approach (fragile)

capturePane → regex match known dialog text → send Down+Enter keystrokes

This is essentially a screen-scraping automation that breaks whenever the upstream TUI changes.

Proposed solution: LLM-based dialog classification

Instead of hardcoding patterns, use a fast/cheap LLM (Haiku or Sonnet) to classify pane content when a worker appears stuck:

1. Capture pane content
2. Send to Haiku/Sonnet with a prompt like: "This is a terminal pane. Is there a confirmation dialog visible? If so, what action should be taken to proceed (accept/dismiss)? Return the keystrokes needed."
3. Execute the returned keystrokes

Benefits:

• Handles any dialog — current and future — without code changes
• Resilient to wording changes
• Can make context-aware decisions (e.g., accept trust prompts but reject destructive confirmations)
• Single implementation covers all dialog types

Cost: One Haiku call per stuck-pane detection (~$0.001 per call), only triggered when a worker appears idle during startup.

Alternative: settings.json pre-configuration

As a complementary approach, omc setup could automatically configure skipDangerousModePermissionPrompt: true and other dialog-suppression settings. But this doesn't cover new dialog types either.

Environment

• omc 4.10.2
• Claude Code 2.1.92
• Observed on both macOS and Linux (WSL2)

[Yeachan-Heo]

Investigating now. I'm opening a dedicated fix session/worktree to inspect the current tmux dialog auto-dismiss path and wire a more robust startup-unblock strategy for worker permission dialogs. I'll follow up here with the PR once the scoped fix is ready.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]