[Bug] Flash crash on startup: Immediate exit with "{}" stdout - v1.0.105

[jensenojs]

Description

I am experiencing a persistent immediate crash upon launching opencode (v1.0.105) on MacOS. The CLI terminates instantly after execution, printing only an empty JSON object {} to stdout.

The issue persists even after a complete cleanup of configuration and cache files.

Steps to Reproduce

1. Run opencode in the terminal (Zsh).
2. The process exits immediately.
3. Output is consistently {}.

Troubleshooting Attempted (Detailed)

I have performed a comprehensive cleanup to rule out environment corruption, but the issue persists in all cases:

1. Checked for Zombie Processes
Verified that no previous opencode instances or background workers were occupying ports or resources.

ps aux | grep opencode
# Result: No process found other than grep.

2. Cleaned State Directories
Removed the following directories to force a fresh start:

• ~/.cache/opencode
• ~/.local/share/opencode
• ~/.local/share/opentui

3. Removed Configuration
Moved ~/.config/opencode/opencode.jsonc to a backup location to test with zero configuration (default state). The crash still occurs.

Logs & Diagnostics

Running with --print-logs shows the service attempts to initialize but terminates immediately after printing the version info, returning the empty JSON.

$ opencode --print-logs
INFO  2025-11-23T05:49:30 +1824ms service=default version=1.0.105 args=["--print-logs"] opencode
{}

OpenCode version

1.0.105

Steps to reproduce

just trying to run opencode

Screenshot and/or share link

Operating System

macOS 26.0.1

Terminal

wezterm

[jensenojs]

This issue is sporadic and not exclusive to v1.0.105. I have encountered this behavior in previous versions as well. It usually resolves itself inexplicably, but currently, it has become persistent and prevents any usage.

[rekram1-node]

hm ill look into it

[jensenojs]

Thanks for the quick reply! @rekram1-node

The issue has actually disappeared for now (classic Heisenbug...), but I'll keep monitoring it and will try to capture more verbose logs if it crashes again.

On a separate note, whenever you get a chance, could I trouble you to take a look at PR #4572 ? I’d really appreciate your thoughts on that one.

Thanks again!

[rekram1-node]

Taking a look at it rn

[rekram1-node]

@jensenojs did this only randomly start happening? Or has this been around for a while?

[jensenojs]

for a while

[jensenojs]

I traced this crash down to the TUI startup path rather than the top-level handler in src/index.ts.

Call chain on startup:

opencode
  -> TuiThreadCommand.handler (src/cli/cmd/tui/thread.ts)
    -> tui({ url, args, onExit }) (src/cli/cmd/tui/app.tsx)
      -> ExitProvider / useExit (src/cli/cmd/tui/context/exit.tsx)
        -> SyncProvider.bootstrap (src/cli/cmd/tui/context/sync.tsx)
           - Promise.all([
               sdk.client.config.providers({ throwOnError: true }),
               sdk.client.provider.list({ throwOnError: true }),
               sdk.client.app.agents({ throwOnError: true }),
               sdk.client.config.get({ throwOnError: true }),
             ])
           - .catch(e => exit(e))

Root cause is in useExit’s error formatting:

  const formatted = FormatError(reason) ?? JSON.stringify(reason)
  process.stderr.write(formatted + "\n")

FormatError only returns a string for a few known domain errors (MCP, provider, config, etc.) or "" for UI.CancelledError. For a “normal” Error thrown from the sdk.client.* calls above, FormatError(reason) is undefined, so the code falls back to JSON.stringify(reason), which results in "{}". That is why any bootstrap failure currently surfaces to the user as just "{}".

I added a FormatUnknownError helper in src/cli/error.ts to format non-domain errors (stack or JSON)

This keeps the existing exit behaviour but prints the underlying error instead of "{}", which should make cases like this much easier to diagnose.

[rekram1-node]

good find, thanks