[Bug]: once opencode upgrade to 1.4.0, oh-my-opencode disappears

[haohaotian1011]

Prerequisites

• I will write this issue in English (see our Language Policy)
• I have searched existing issues to avoid duplicates
• I am using the latest version of oh-my-opencode
• I have read the documentation or asked an AI coding agent with this project's GitHub URL loaded and couldn't find the answer

Bug Description

all agents cannot be seen.

Steps to Reproduce

upgrade opencode to 1.4.0
then all agetns disappear.

Expected Behavior

should be still there.

Actual Behavior

cannot be seen

Doctor Output

oMoMoMoMo... Doctor 


Installation
────────────────────────────────────────
  ✓ OpenCode Installation → 1.4.0
  ✓ Plugin Registration → Registered

Configuration
────────────────────────────────────────
  ✓ Configuration Validity → Valid JSON config

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

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

Tools & Servers
────────────────────────────────────────
  ⚠ GitHub CLI → 2.89.0 - not authenticated
  ✓ LSP Servers → 1/4 servers available
  ✓ Built-in MCP Servers → 2 built-in servers enabled
  ○ User MCP Configuration → No user MCP configuration found

Updates
────────────────────────────────────────
  ✓ Version Status → Up to date (3.15.3)

Summary
────────────────────────────────────────

  8 passed, 0 failed, 3 warnings, 3 skipped
  Total: 14 checks in 2323ms

⚠ All systems operational with warnings.

Error Logs

Configuration

Additional Context

No response

Operating System

ubuntu22.04

OpenCode Version

1.4.0

[code-yeongyu]

Thanks for reporting this! This is the second report of agents disappearing after OpenCode 1.4.0 upgrade (see also #3219).

We're investigating the root cause. OpenCode 1.4.0 (released today) includes SDK breaking changes that likely affect how our plugin registers agents.

Could you help us narrow this down? Please run the following and paste the output:

# Check if the model cache exists
ls -la ~/.cache/oh-my-opencode/ 2>/dev/null || echo 'cache dir not found'
cat ~/.cache/oh-my-opencode/connected-providers.json 2>/dev/null || echo 'no connected-providers cache'
cat ~/.cache/oh-my-opencode/provider-models.json 2>/dev/null || echo 'no provider-models cache'

# Check OpenCode's plugin loading logs
opencode --print-logs 2>&1 | grep -i 'oh-my\|omo\|agent.*loaded\|config.*handler' | head -30

Also, could you try downgrading OpenCode to 1.3.x to confirm the agents come back? That would confirm the 1.4.0 regression.

# Downgrade test
npm install -g @anthropic-ai/opencode@1.3.17
# or
bun install -g @anthropic-ai/opencode@1.3.17

We'll keep this linked with #3219 as they appear to share the same root cause.

[BrahmingWu]

+1

[Cicaba]

I tried to downgrade to OpenCode 1.3.17 version in Linux environment, but it could not be restored.

[vega-arclight]

Encountering the same issue in versions 1.4.0 and 1.3.17. Downgrading to 1.3.9 resolved it for me (Linux environment)

[qiuqp]

+1

[leiyang0426]

i also have this question,i think the main error is in the picture

i have run command to install oh-my-opencode,but it not work

[JungleJul]

same problem

[AlexKuai]

The same problem was resolved by downgrading to version 1.3.13.

[Goodboy-dai]

I asked my own OpenCode setup to diagnose the issue autonomously, and it eventually succeeded in loading oh-my-opencode on OpenCode 1.3.17.(the stable version works well with omo v3.15.3)
That suggests there is at least a temporary workaround for this issue.
Based on that investigation, I confirmed that the plugin can still work on 1.3.17, and I documented the workaround that made it load successfully in my environment.

Working workaround for oh-my-openagent / oh-my-opencode load issues on OpenCode 1.3.13+

I hit the same plugin-loading problem reported by others after OpenCode 1.3.13+
After testing this locally, I found that the plugin itself was not the main problem. The more immediate issue was OpenCode's remote npm plugin installation path.
This workaround made the plugin load successfully for me.

What is going wrong?

On OpenCode 1.3.13+, oh-my-openagent / oh-my-opencode may fail to load agents or hang at startup.

Main idea of the workaround

Instead of letting OpenCode install the plugin from npm by itself, install the plugin manually with npm, then point OpenCode directly to the local plugin directory.
This bypasses OpenCode's broken remote plugin install path.

Exact steps

Step 1. Install the plugin manually with npm

Run:

npm install --prefix ~/.config/opencode oh-my-openagent@v3.15.3

What each part means

• npm install
  • Tells npm to install a package.
• --prefix ~/.config/opencode
  • Tells npm to treat ~/.config/opencode as the install target directory.
  • This means npm will create or update:
    • ~/.config/opencode/package.json
    • ~/.config/opencode/package-lock.json
    • ~/.config/opencode/node_modules/
• oh-my-openagent@v3.15.3
  • Installs the v3.15.3 version of the plugin package.
  • I used the renamed package identity here because current docs prefer oh-my-openagent.

What this step should produce

After this command, the plugin should exist at:

~/.config/opencode/node_modules/oh-my-openagent

That local directory is the key to the workaround.

Step 2. Edit ~/.config/opencode/opencode.json

If your config currently looks like this:

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": [
    "oh-my-openagent"
  ]
}

change it to this:

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": [
    "/home/YOUR_USERNAME/.config/opencode/node_modules/oh-my-openagent"
  ]
}

What each line means

• "plugin": [
  • This starts the list of plugins that OpenCode should load.
• "/home/YOUR_USERNAME/.config/opencode/node_modules/oh-my-openagent"
  • This is the important part.
  • Instead of telling OpenCode to download the plugin by package name, this tells OpenCode to load the plugin directly from a local filesystem path.
  • This avoids the broken npm/arborist/Bun install path entirely.

Important note

Use the full absolute path.
Do not rely on this form inside JSON:

"~/.config/opencode/node_modules/oh-my-openagent"

because ~ is a shell feature, not guaranteed JSON path expansion.

Step 3. Rename the plugin config file to the new preferred name

If you already have an old config file like this:

~/.config/opencode/oh-my-opencode.json

rename or copy it to:

~/.config/opencode/oh-my-openagent.json

For example:

mv ~/.config/opencode/oh-my-opencode.json ~/.config/opencode/oh-my-openagent.json

What this command does

• mv
  • Moves or renames a file.
• ~/.config/opencode/oh-my-opencode.json
  • The old legacy plugin config filename.
• ~/.config/opencode/oh-my-openagent.json
  • The new preferred plugin config filename.
    Why this matters

The compatibility layer still recognizes old names, but current docs prefer:

• plugin entry: oh-my-openagent
• plugin config file: oh-my-openagent.json or oh-my-openagent.jsonc
  So renaming reduces compatibility-edge confusion.

Why this workaround helps

OpenCode's failing path is:

1. read plugin name from opencode.json
2. try to fetch/install it from npm internally
3. fail in the npm/arborist/Bun path
4. plugin never becomes available
5. built-in default agent gets used instead
   The workaround changes that flow to:
6. install plugin yourself with normal npm
7. point OpenCode directly to the already-installed local plugin directory
8. OpenCode loads the plugin from disk
9. no broken remote install step is needed

Conclusion

If oh-my-openagent or oh-my-opencode is not loading on OpenCode 1.3.13+,

this worked for me:

1. install the plugin manually with npm
2. point plugin to the local installed directory
3. rename plugin config to oh-my-openagent.json

This is currently the most reliable workaround I found until OpenCode fixes the remote npm plugin installation path.

[Aice-c]

Confirmed on Windows 11 + Zed ACP.

Before OpenCode 1.4.x, OpenCode + oh-my-openagent worked for me in Zed.
After upgrading OpenCode, Zed fails to launch with:
"default agent "Sisyphus - Ultraworker" not found"

If I point Zed to a clean OpenCode config without omo loaded, OpenCode ACP works again.
So this looks like an omo registration / initialization issue in ACP mode after the OpenCode 1.4 upgrade, not a generic Zed ACP failure.

[CloudWarGit]

+1

[xygengcn]

same，opencode tui is blank, opencode web can't reach. ~/.cache/oh-my-opencode isn't exist

[dqbpqdpb]

I spent nearly 2 hours debugging before I remembered to check the issues. Here is my situation:

Environment:
- opencode: 1.4.1
- oh-my-opencode: 3.16.0
- oh-my-openagent: 3.16.0
- OS: Debian (Linux)

 Test Results:

 1. Pure mode (without plugin) - WORKS:
       opencode run "hello" --pure --model cpamc/gpt-5.4
       → cpamc provider works fine, no maxOutputTokens error

 2. With plugin (non-pure) - FAILS:
       opencode run "hello" --print-logs
       → Error: default agent "Sisyphus - Ultraworker" not found

 3. Background agent call (via explore/librarian) - FAILS:
    → Error: Invalid argument for parameter maxOutputTokens: maxOutputTokens must be >= 1

 Root Cause:
 The plugin loading fails in opencode 1.4.0+, causing agents not to be registered properly. This breaks both agent lookup and causes cascading issues with model parameter passing.

 Workaround:
 Use --pure mode to bypass plugin loading:

 opencode run "your task" --pure --model cpamc/gpt-5.4