[Bug]: v3.1.9 causes TUI freeze/blank screen - CRITICAL REGRESSION

[rooftop-Owl]

Prerequisites

• I will write this issue in English
• I have searched existing issues to avoid duplicates
• I am using the latest version of oh-my-opencode (reproduced on v3.1.9)
• I have read the documentation

Bug Description

CRITICAL: oh-my-opencode v3.1.9 (released Jan 30, 2026) causes OpenCode TUI to freeze with a blank screen immediately upon launch, rendering OpenCode completely unusable.

Steps to Reproduce

1. Update to oh-my-opencode v3.1.9 (or use oh-my-opencode@latest)
2. Configure with multiple auth providers (tested with Anthropic + OpenAI + Google Antigravity)
3. Launch OpenCode: opencode
4. Observe: TUI appears but is completely frozen/blank - no interactive elements render

Expected Behavior

OpenCode TUI should initialize normally and display the chat interface with agent selection, similar to behavior in v3.1.8.

Actual Behavior

TUI window opens but remains frozen with a blank/unresponsive screen. No error messages displayed in the UI. Process does not crash but requires manual termination (Ctrl+C).

Doctor Output

 oMoMoMoMo... Doctor 

Installation
────────────────────────────────────────
  ✓ OpenCode Installation → 1.1.45
  ✓ Plugin Registration → Registered (pinned: 3.1.8)

Configuration
────────────────────────────────────────
  ✓ Configuration Validity → Valid JSON config
  ✓ Model Resolution → 9 agents, 8 categories (8 overrides), 2369 available

Authentication
────────────────────────────────────────
  ✓ Anthropic (Claude) Auth → Auth plugin available
  ✓ OpenAI (ChatGPT) Auth → Auth plugin available
  ✓ Google (Gemini) Auth → Auth plugin available

Dependencies
────────────────────────────────────────
  ✓ AST-Grep CLI → installed
  ✓ AST-Grep NAPI → installed
  ⚠ Comment Checker → Not installed (optional)

Tools & Servers
────────────────────────────────────────
  ✓ GitHub CLI → 2.85.0
  ✓ LSP Servers → 1/4 servers available
  ✓ Built-in MCP Servers → 2 built-in servers enabled
  ✓ User MCP Configuration → 4 user server(s) configured

Summary
────────────────────────────────────────
  14 passed, 0 failed, 1 warnings, 1 skipped

Configuration

{
  "plugin": [
    "opencode-antigravity-auth@1.4.3",
    "opencode-openai-codex-auth",
    "opencode-anthropic-auth@0.0.13",
    "oh-my-opencode@3.1.9"
  ]
}

Additional Context

✅ CONFIRMED WORKAROUND

Pinning to oh-my-opencode@3.1.8 resolves the issue completely:

{
  "plugin": ["oh-my-opencode@3.1.8"]
}

🔍 SUSPECTED ROOT CAUSE (unconfirmed)

Based on v3.1.9 changelog, suspect commits include:

• 80ee52f: Model resolution with client API fallback
• 1187a02: Atlas fallback chain + provider-models cache refresh

The new model resolution logic may be causing an initialization deadlock or race condition when multiple auth providers are configured.

📊 IMPACT

• Severity: CRITICAL - Plugin completely unusable
• Scope: Users with multi-provider configurations (possibly all users)
• Timeline: Started ~1 hour after v3.1.9 release (Jan 30, 2026 14:00 UTC)

🚨 RECOMMENDATION

Consider reverting v3.1.9 or publishing v3.1.10 with the regression fix until root cause is identified.

Operating System

Linux (RHEL 8.9, kernel 4.18.0-513.5.1.el8_9.x86_64)

OpenCode Version

1.1.45

[rooftop-Owl]

Related Pattern: Multiple v3.1.9 Initialization Regressions

Cross-reference: #1291 reports a separate v3.1.9 regression (Bun segmentation fault on Windows during LSP server initialization).

Pattern observed:

• [Bug]: Bun crash (Segmentation Fault) caused by lsp_diagnostics missing typescript-language-server on Windows #1291: Windows - Bun segfault when typescript-language-server missing during LSP init
• [Bug]: v3.1.9 causes TUI freeze/blank screen - CRITICAL REGRESSION #1292 (this issue): Linux - TUI freeze during multi-provider model resolution

Both issues:

• ✅ Introduced in v3.1.9 (released Jan 30, 2026)
• ✅ Affect initialization/startup paths
• ✅ Resolved by pinning to v3.1.8
• ✅ Suggest broken error handling or race conditions in initialization logic

This pattern indicates v3.1.9 may have introduced systemic initialization fragility across multiple code paths, not just a single isolated bug.

[rooftop-Owl]

✅ ROOT CAUSE IDENTIFIED

The issue is a version mismatch caused by upstream OpenCode, NOT oh-my-opencode.

Version Timeline:

OpenCode CLI:           v1.1.45 ✅ Released today (Jan 30)
@opencode-ai/plugin:    v1.1.44 ❌ NOT updated (stuck at v1.1.44)
oh-my-opencode v3.1.9:  ❌ Expects plugin@1.1.45 (doesn't exist)

Evidence:

# Verify plugin package versions on npm
$ npm view @opencode-ai/plugin versions --json | tail -5
  "1.1.41",
  "1.1.42",
  "1.1.43",
  "1.1.44"    # ← Latest (v1.1.45 missing!)
]

# Verify our OpenCode CLI version
$ opencode --version
1.1.45         # ← Released today

What's Happening:

1. oh-my-opencode v3.1.9 tries to load @opencode-ai/plugin@1.1.45
2. Bun/npm fails to resolve (package doesn't exist on npm)
3. Plugin load hangs indefinitely
4. TUI freezes waiting for dependency resolution

Solution Path:

Short-term (for users):

• ✅ Pin to oh-my-opencode@3.1.8 (confirmed working)
• ⏳ Wait for upstream to publish @opencode-ai/plugin@1.1.45

Long-term (for maintainers):

• 🔧 oh-my-opencode should handle missing plugin versions gracefully (timeout + fallback)
• 🔧 Upstream OpenCode should ensure @opencode-ai/plugin publishes in sync with CLI releases

Related:

• Same finding reported by @msis in [Bug]: OpenCode shows blank screen after installing oh-my-opencode plugin on macOS #596 (4 hours ago)
• [Bug]: OpenCode shows blank screen after installing oh-my-opencode plugin on macOS #596 now has reports of the SAME v3.1.9 issue (not just original network timeout)

Upstream Issue:

This should be reported to https://github.com/sst/opencode as a release process bug - they published CLI v1.1.45 without publishing the matching plugin package.

[rooftop-Owl]

🎯 CONSOLIDATED SUMMARY (Final Update)

Root Cause (CONFIRMED)

Upstream OpenCode published CLI v1.1.45 without publishing the matching plugin package to npm.

OpenCode CLI:           v1.1.45 ✅ (published to npm today)
@opencode-ai/plugin:    v1.1.44 ❌ (stuck at old version)
oh-my-opencode v3.1.9:  ❌ (expects non-existent @1.1.45)
Result:                 🔴 Dependency resolution hangs → TUI freezes

Initial hypothesis (model resolution/cache issues) was incorrect. The freeze happens during plugin dependency resolution, not model initialization.

---

Evidence

# Plugin package missing from npm
$ npm view @opencode-ai/plugin versions --json | tail -5
  "1.1.41",
  "1.1.42",
  "1.1.43",
  "1.1.44"    # ← Latest published (v1.1.45 missing!)
]

# But OpenCode CLI expects v1.1.45
$ opencode --version
1.1.45

# Same error logs reported in #596 today
error: No version matching "1.1.45" found for specifier "@opencode-ai/plugin"
error: @opencode-ai/plugin@1.1.45 failed to resolve

---

Related Issues

Issue	Platform	Symptom	Root Cause
#596	macOS	Blank screen (Jan 8 - network timeout)	Version pinning issue (RESOLVED)
#596	macOS	Blank screen (Jan 30 - v3.1.9)	Same as this issue (missing plugin@1.1.45)
#1291	Windows	Bun segfault	Separate v3.1.9 regression (LSP init)
#1292	Linux	TUI freeze	This issue (missing plugin@1.1.45)

All v3.1.9 blank screen reports share the same root cause.

---

Workaround (For Users)

{
  "plugin": [
    "oh-my-opencode@3.1.8"  // ← Pin to last working version
  ]
}

Why this works: v3.1.8 expects older plugin versions that DO exist on npm.

---

Fix Requirements

Upstream OpenCode (immediate):

• 📦 Publish @opencode-ai/plugin@1.1.45 to npm
• 🔧 Fix release process to ensure plugin publishes in sync with CLI

oh-my-opencode (defensive improvement):

• ⏱️ Add timeout for dependency resolution (fail fast, not hang)
• 📝 Show user-friendly error when plugin version missing
• 🛡️ Graceful fallback to older plugin versions

---

Closing Criteria

This issue can be closed when EITHER:

• ✅ Upstream publishes @opencode-ai/plugin@1.1.45 AND oh-my-opencode releases v3.1.10 supporting it
• ✅ oh-my-opencode releases v3.1.10 with defensive handling (timeout + fallback)

Until then, users should remain pinned to v3.1.8.

[zenmequmingzia]

same issue on mac os26

[imadraude]

Can confirm that upgrading to OpenCode v1.1.47 (and the now-available @opencode-ai/plugin@1.1.47) resolves the initialization hangs and dependency errors.

Run opencode upgrade or reinstall via npm to get the fix.

[rooftop-Owl]

✅ RESOLVED - Upstream Fix Confirmed

Verification Results:

# Current environment (as of 2026-01-31)
$ opencode --version
1.1.47

$ npm view @opencode-ai/plugin versions --json | tail -10
  "1.1.41",
  "1.1.42",
  "1.1.43",
  "1.1.44",
  "1.1.45",  # ← Now published
  "1.1.46",  # ← Now published
  "1.1.47"   # ← Now published
]

What Was Fixed

Upstream OpenCode published the missing plugin packages:

• @opencode-ai/plugin@1.1.45 (was blocking v3.1.9)
• @opencode-ai/plugin@1.1.46
• @opencode-ai/plugin@1.1.47 (current)

The dependency resolution hang is now resolved. TUI initializes normally.

For Users Still Experiencing Issues

If you're still seeing blank screens or freezes:

1. Upgrade OpenCode:

   opencode upgrade
   # or
   npm install -g @opencode-ai/cli@latest

2. Verify version:

   opencode --version  # Should show 1.1.47 or higher

3. Unpin oh-my-opencode (if you pinned to v3.1.8):

   {
     "plugin": ["oh-my-opencode"]  // Use latest
   }

4. Restart OpenCode:

   opencode

Credits

Thank you to @imadraude for confirming the fix and to everyone who reported the issue promptly!

---

Closing as resolved. Issue was caused by upstream release process gap (CLI published without matching plugin package). Upstream has corrected this and published all missing versions.

If anyone still experiences TUI freezes on v1.1.47+, please open a new issue with updated diagnostics.

[rooftop-Owl]

❌ CORRECTION - Issue NOT Fixed (Re-opening)

I apologize for prematurely closing this issue. The problem is NOT resolved.

Evidence of Ongoing Issue

Multiple users continue reporting identical symptoms after v1.1.47 release:

Issue	Date	OpenCode	oh-my-opencode	Platform
#1301	Jan 30, 21:54	v1.1.25	v3.1.9	macOS (Apple Silicon)
#1305	Jan 30, 23:16	v1.1.47	v3.1.9	Raspberry Pi / ARM64
#1300	Jan 30, 19:58	(not specified)	latest	Windows

All report identical symptom: TUI hangs on blank screen after oh-my-opencode loads.

---

Real Root Cause (Updated Analysis)

The plugin version mismatch hypothesis was incorrect. The actual issue is in oh-my-opencode v3.1.9 itself.

Key Evidence from #1305 logs:

[2026-01-30T23:15:30.398Z] [fetchAvailableModels] CALLED {"connectedProvidersUnknown":true}
<EOF — nothing more, TUI stays black>

What's happening:

1. oh-my-opencode v3.1.9 loads successfully
2. fetchAvailableModels() is called during initialization
3. The function blocks indefinitely (network timeout? infinite loop? race condition?)
4. Blocking call prevents TUI from rendering
5. Process hangs silently with no error message

Comparison with working version (v3.0.0-beta.1):

• Initialization completes normally after plugins load
• Bus subscriptions, LSP servers, MCP connections all proceed
• Log files: 58KB (full initialization)

Broken version (v3.1.8 / v3.1.9):

• Initialization stops after plugins load
• No bus subscriptions, no LSP, no MCP, no provider discovery
• Log files: 3-6KB (truncated at fetchAvailableModels)

---

Why v1.1.47 Didn't Fix It

Upstream published @opencode-ai/plugin@1.1.47, which resolved the dependency resolution issue. However, that was a red herring.

The real bug is in oh-my-opencode v3.1.9's model resolution logic, specifically:

• fetchAvailableModels() function
• connected-providers-cache error handling
• Possible race condition when connectedProvidersUnknown: true

---

Confirmed Workaround

Pin to oh-my-opencode v3.1.8 or earlier:

{
  "plugin": ["oh-my-opencode@3.1.8"]
}

Why this works: v3.1.8 and earlier don't have the blocking bug in fetchAvailableModels.

---

Action Items

For oh-my-opencode maintainers:

1. Investigate fetchAvailableModels() in v3.1.9

   • Check for blocking network calls without timeout
   • Review connected-providers-cache error handling
   • Test with connectedProvidersUnknown: true condition

2. Reproduce the issue:

   • Test on macOS (Apple Silicon), Raspberry Pi (ARM64), Windows
   • Test with multiple auth providers configured
   • Compare logs between v3.1.8 (working) and v3.1.9 (broken)

3. Consider hotfix release (v3.1.10):

   • Revert suspected commits (80ee52f, 1187a02 mentioned in original report)
   • OR add timeout/fallback to fetchAvailableModels()
   • OR make model resolution non-blocking

---

For Users

Current recommendation: Remain on oh-my-opencode@3.1.8 until a fix is released.

Upgrading OpenCode to v1.1.47 is safe but does not resolve this issue.

---

Status: Re-opening as CRITICAL - Plugin completely unusable on v3.1.9 for multi-provider configurations.

Apologies for the confusion. The upstream plugin publication was a separate (resolved) issue that coincidentally appeared at the same time.

[code-yeongyu]

Fixed in v3.1.10 via PR #1304.

Root cause: fetchAvailableModels() was calling client.provider.list() during plugin initialization, causing a deadlock:

• Plugin init waits for server response
• Server waits for plugin init to complete

Fix: Changed to cache-only mode during init by passing undefined instead of client to fetchAvailableModels().

Please update to oh-my-opencode@3.1.10:

bunx oh-my-opencode@3.1.10 install