[Bug]: OpenCode provider health check fails on OpenCode CLI 1.18.23 (models --json unsupported)

[Mostafa-Ben-Git]

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area: apps/desktop

Steps to reproduce

1. Install OpenCode CLI (latest stable 1.18.23, e.g. via scoop install opencode) and authenticate (opencode auth login). Confirm opencode models works.
2. Install T3 Code desktop 0.0.35 (e.g. via Scoop Extras) and open it.
3. Look at the OpenCode provider entry in the agent list / connection status.

Expected behavior
The OpenCode provider should show as available/healthy, since the CLI is installed and opencode models succeeds.

Actual behavior
OpenCode is shown as "Unavailable" with:

OpenCode v1.18.23 Unavailable - Failed to execute OpenCode CLI health check: OpenCode models command exited with code 1.

Root cause
The health check invokes the OpenCode CLI with a flag the current stable release does not support. Verified directly on Windows:

> opencode models --json
opencode models [provider]
list all available models
Positionals:
 provider provider ID to filter models by [string]
Options:
 -h, --help show help [boolean]
 -v, --version show version number [boolean]
 --print-logs print logs to stderr [boolean]
 --log-level log level [string] [choices: "DEBUG","INFO","WARN","ERROR"]
 --pure run without external plugins [boolean]
 --verbose use more verbose model output (includes metadata like costs) [boolean]
 --refresh refresh the models cache from models.dev [boolean]
exit code: 1

opencode models --json exits 1 because --json is not a supported flag in 1.18.23 (the models subcommand only accepts [provider], --verbose, --refresh, --pure, --print-logs, --log-level, --help, --version). Plain opencode models exits 0 and lists models fine. So the CLI itself is healthy; the health check is sending an argument the released CLI rejects.

Impact: Major degradation or frequent failure — OpenCode cannot be used as a provider from T3 Code with the current stable OpenCode release.

Version or commit

• T3 Code: 0.0.35
• OpenCode: 1.18.23 (latest stable on both Scoop main and npm opencode-ai@latest)

Environment
Windows 11, Scoop-installed opencode@1.18.23, T3 Code 0.0.35 (Scoop Extras), OpenCode credentials present (opencode auth list shows 3 entries).

Logs
See "Root cause" above — opencode models --json returns exit code 1 with the usage text on stderr.

Workaround
None stable. scoop update opencode reports 1.18.23 is already latest, and npm opencode-ai@latest is also 1.18.23, so there is no newer stable CLI that adds --json. Two possible fixes:

• T3 Code's health check should not require --json (parse plain opencode models output, or use a flag that exists in 1.18.23), or
• OpenCode should ship --json support on the models command (and T3 Code can then rely on it once released).

[Mostafa-Ben-Git]

Correction on the root cause — my initial --json theory was wrong, and the fix is already in the codebase. Posting accurate findings so maintainers aren't chasing the wrong flag.

What the code actually does

In apps/server/src/provider/opencodeRuntime.ts → loadInventoryFromCli, the model inventory is loaded with:

const runModelsCli = () =>
 runOpenCodeCommand({ binaryPath: input.binaryPath, args: ["models", "--verbose"], ... })

I checked both main and the v0.0.35 tag (the release this was filed against): both use models --verbose, and there are zero references to models --json anywhere in the file. So the released app does not send --json.

opencode models --verbose works fine standalone

On OpenCode 1.18.23 (current stable on Scoop main and npm opencode-ai@latest), opencode models --verbose exits 0 and prints the full model list (including per-model cost/capabilities JSON). So the CLI/flag is healthy.

Why it still fails inside T3 Code

The error text OpenCode models command exited with code 1 is exactly what loadInventoryFromCli emits when modelsResult.value.code !== 0. So the CLI does exit 1 — but only in the environment T3 Code spawns it, which differs from a normal shell.

The likely trigger is the spawn context in OpenCodeProvider.ts → loadInventoryFromCli:

• environment is passed as resolvedEnvironment = environment ?? process.env. Because an environment object is provided, runOpenCodeCommand then forces OPENCODE_CONFIG_CONTENT via resolveOpenCodeConfigContent(...), which defaults to "{}" when nothing else is set.
• My standalone test invoked opencode models --verbose with the normal user environment (real config) → exit 0. I could not reproduce exit 1 in a plain shell, which points at the environment T3 Code injects rather than the command itself.

Ask

Could a maintainer confirm whether the forced/empty OPENCODE_CONFIG_CONTENT (or another variable inherited from the Electron process.env, e.g. ELECTRON_RUN_AS_NODE) causes opencode models --verbose to exit 1 in the spawned context? The repro (OpenCode shows "Unavailable" with that exact message) is still valid — it's just not the --json flag I originally blamed.

Thanks for the patience.

[Mostafa-Ben-Git]

I've opened a fix for this in #8391 — it ports the pending parser fixes (#7834, #7988) and improves the models error diagnostics. With those, the health check no longer drops models with spaces or leaks OSC escapes, and a future exited with code 1 will include stderr/stdout.

[Newarr]

+1. I’m seeing this with T3 Code 0.0.36-nightly.20260828.1209 and OpenCode 1.18.25 on macOS.

I managed to reproduce the failure by starting the three health check commands at once. It failed on the fourth run with:

Error: Unexpected error

database is locked

All three commands work when run alone.

T3 Code starts them in parallel, then retries any failures together after one second. That retry can hit the same lock again. OpenCode sets SQLite busy_timeout to 0, so even a brief collision fails immediately.

PR #4153 mentions this lock error, but the retry does not remove the race. I think these health check commands need to run one at a time.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing as fixed by PR #8480. Provider discovery now reads OpenCode's catalog over HTTP through a managed or configured server. It no longer runs the parallel inventory CLI commands that reproduced the SQLite lock in the later comment.

This is part of an automated closure pass based on our investigation. The fix is included in v0.0.38.

If we missed something, please reply with the T3 Code version and reproduction details, and we can reopen it.