Skip to content

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

Closed
Closed
[Bug] Flash crash on startup: Immediate exit with "{}" stdout - v1.0.105#4650
Assignees
rekram1-node
Labels
bugSomething isn't working

Description

@jensenojs
jensenojs
opened on Nov 23, 2025

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

Image

Operating System

macOS 26.0.1

Terminal

wezterm

Activity

  1. jensenojs
    added
    bugSomething isn't working
    on Nov 23, 2025
  2. github-actions
    added
    opentuiThis relates to changes in v1.0, now that opencode uses opentui
    on Nov 23, 2025
  3. rekram1-node
    self-assigned this
    on Nov 23, 2025
  4. rekram1-node
    removed
    opentuiThis relates to changes in v1.0, now that opencode uses opentui
    on Nov 23, 2025

  5. jensenojs commented on Nov 23, 2025

    @jensenojs
    jensenojs
    on Nov 23, 2025
    ContributorAuthor

    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.

  6. rekram1-node commented on Nov 23, 2025

    @rekram1-node
    rekram1-node
    on Nov 23, 2025
    Contributor

    hm ill look into it

  7. jensenojs commented on Nov 23, 2025

    @jensenojs
    jensenojs
    on Nov 23, 2025
    ContributorAuthor

    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!

  8. rekram1-node commented on Nov 23, 2025

    @rekram1-node
    rekram1-node
    on Nov 23, 2025
    Contributor

    Taking a look at it rn

  9. rekram1-node commented on Nov 23, 2025

    @rekram1-node
    rekram1-node
    on Nov 23, 2025
    Contributor

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

  10. jensenojs commented on Nov 23, 2025

    @jensenojs
    jensenojs
    on Nov 23, 2025
    ContributorAuthor

    for a while

  11. jensenojs commented on Nov 26, 2025

    @jensenojs
    jensenojs
    on Nov 26, 2025
    ContributorAuthor

    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.

  12. rekram1-node commented on Nov 26, 2025

    @rekram1-node
    rekram1-node
    on Nov 26, 2025
    Contributor

    good find, thanks

  13. jensenojs
    closed this as completedon Nov 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions