Description
When the opencode CLI process runs continuously for approximately 12-15 hours, an internal periodic task ("booting location services") that fires every ~2 hours stops triggering. After this happens, the process can still detect stdin input (logged as loop step=0) but never starts LLM processing — no "stream" or "process" event follows the input detection. The user is forced to restart opencode to create a new session.
Evidence from local DB and logs
The booting location services event appears on a ~2-hour cycle in opencode.log. In every affected session, the last occurrence is the terminal one:
| Session |
Runtime before stall |
Last location-services boot |
User input after |
Result |
| ses_0f8b6 |
~22h |
20:15 (event #7) |
next day 03:08 |
loop detected, no processing |
| ses_0f249c |
~15.5h |
00:11 (event #9) |
01:44 |
loop detected, no processing |
| ses_0f3cc |
~7h |
N/A (killed mid-stream) |
10:10 |
error=Aborted (disposing all instances) |
Log excerpt for ses_0f249c (last ~2h-cycle boots)
20:11:45 booting location services (event #7)
22:11:49 booting location services (event #8)
00:11:54 booting location services (event #9) ← LAST ONE
01:44:55 loop step=0 (input detected)
← NO "process" event follows
The next expected boot at ~02:11 never fired.
Root cause hypothesis
The opencode CLI is a sea-node (Node.js compiled into an ELF binary). After extended runtime, the internal setInterval/setTimeout mechanism that drives location-services refresh and possibly other scheduler tasks appears to collapse. The process remains alive (stdin readable, watcher operational) but can no longer initiate new LLM streaming.
Contributing factors observed:
- Process uses ~780 MB RSS with 30+ threads
- Three plugins loaded (voice, rtk, preprocessor) that hook into event pipeline
- The file watcher accumulates state over hours
Impact
Users running opencode CLI in long-lived terminal sessions (tmux, screen, SSH) will find that after ~12-15 hours, new messages produce no response. The session appears stuck. Restarting opencode resolves the issue temporarily.
Workaround
Restart opencode periodically (e.g., daily) to reset the process state. Or use the desktop app which has different lifecycle management.
Environment
- opencode version: 1.17.9 (also confirmed on 1.17.11)
- Platform: Linux aarch64 (ARM64)
- Mode:
build (CLI/TUI)
- Transport: tmux session
Description
When the opencode CLI process runs continuously for approximately 12-15 hours, an internal periodic task ("booting location services") that fires every ~2 hours stops triggering. After this happens, the process can still detect stdin input (logged as
loop step=0) but never starts LLM processing — no "stream" or "process" event follows the input detection. The user is forced to restart opencode to create a new session.Evidence from local DB and logs
The
booting location servicesevent appears on a ~2-hour cycle inopencode.log. In every affected session, the last occurrence is the terminal one:Log excerpt for ses_0f249c (last ~2h-cycle boots)
The next expected boot at ~02:11 never fired.
Root cause hypothesis
The opencode CLI is a sea-node (Node.js compiled into an ELF binary). After extended runtime, the internal
setInterval/setTimeoutmechanism that drives location-services refresh and possibly other scheduler tasks appears to collapse. The process remains alive (stdin readable, watcher operational) but can no longer initiate new LLM streaming.Contributing factors observed:
Impact
Users running opencode CLI in long-lived terminal sessions (tmux, screen, SSH) will find that after ~12-15 hours, new messages produce no response. The session appears stuck. Restarting opencode resolves the issue temporarily.
Workaround
Restart opencode periodically (e.g., daily) to reset the process state. Or use the desktop app which has different lifecycle management.
Environment
build(CLI/TUI)