anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-23 10:45:33 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Closed
opened 2026-02-16 17:38:25 -05:00 by yindo · 8 comments
yindo commented 2026-02-16 17:38:25 -05:00
Owner
Copy Link
Copy Source

Originally created by @jensenojs on GitHub (Nov 23, 2025).

Originally assigned to: @rekram1-node on GitHub.

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

Originally created by @jensenojs on GitHub (Nov 23, 2025). Originally assigned to: @rekram1-node on GitHub. ### 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. ```bash 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. ```text $ 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 <img width="1208" height="697" alt="Image" src="https://github.com/user-attachments/assets/3d9b18f4-66f9-4f84-b1c6-0b5863fea9b5" /> ### Operating System macOS 26.0.1 ### Terminal wezterm
yindo added the bug label 2026-02-16 17:38:25 -05:00
yindo closed this issue 2026-02-16 17:38:25 -05:00
yindo commented 2026-02-16 17:38:25 -05:00
Author
Owner
Copy Link
Copy Source

@jensenojs commented on GitHub (Nov 23, 2025):

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.

@jensenojs commented on GitHub (Nov 23, 2025): 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.
yindo commented 2026-02-16 17:38:25 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 23, 2025):

hm ill look into it

@rekram1-node commented on GitHub (Nov 23, 2025): hm ill look into it
yindo commented 2026-02-16 17:38:25 -05:00
Author
Owner
Copy Link
Copy Source

@jensenojs commented on GitHub (Nov 23, 2025):

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!

@jensenojs commented on GitHub (Nov 23, 2025): 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!
yindo commented 2026-02-16 17:38:26 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 23, 2025):

Taking a look at it rn

@rekram1-node commented on GitHub (Nov 23, 2025): Taking a look at it rn
yindo commented 2026-02-16 17:38:26 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 23, 2025):

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

@rekram1-node commented on GitHub (Nov 23, 2025): @jensenojs did this only randomly start happening? Or has this been around for a while?
yindo commented 2026-02-16 17:38:26 -05:00
Author
Owner
Copy Link
Copy Source

@jensenojs commented on GitHub (Nov 23, 2025):

for a while

@jensenojs commented on GitHub (Nov 23, 2025): for a while
yindo commented 2026-02-16 17:38:26 -05:00
Author
Owner
Copy Link
Copy Source

@jensenojs commented on GitHub (Nov 26, 2025):

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.

@jensenojs commented on GitHub (Nov 26, 2025): 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.
yindo commented 2026-02-16 17:38:26 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 26, 2025):

good find, thanks

@rekram1-node commented on GitHub (Nov 26, 2025): good find, thanks
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3062
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?