Sessions permanently stuck during normal use — survive reboots, cannot be recovered

Description

Multiple sessions became permanently "stuck" (refusing new messages) during normal use. The stuck state persists across full system reboots and cannot be cleared by restarting the opencode server. The sessions are visible in the API and database, but any attempt to send a message to them silently fails. This is not triggered by a crash or power outage — sessions worked normally for days after the last known interruption, then suddenly became unresponsive.

Environment

OpenCode version: 1.17.3
OS: Linux (Debian/Ubuntu)
Installation: /home/dwc/.opencode/bin/opencode (156 MB binary)
Server mode: opencode web --hostname 0.0.0.0 (port 4096 with auth)
Database: ~/.local/share/opencode/opencode.db (776 MB, SQLite 3.x)
Models used: deepseek-v4-flash-free, mimo-v2.5-free (via opencode provider)

Affected Sessions

Session ID	Title	Last Assistant Response	Last User Message	Messages
`ses_08513899fffe1yQ0ScYtryRBXN`	TTS-Ebook	2026-08-13 20:32 UTC	2026-08-17 13:43 UTC	842
`ses_0bc91dc31ffeBCZdqPJ2s02vYY`	Web2Epub	2026-08-10 15:16 UTC	2026-08-17 13:43 UTC	2258
`ses_1494d504dffeekKczywChTegQc`	Local machine and NAS	2026-08-08 19:02 UTC	2026-08-17 19:56 UTC	847

Note: A power outage occurred on August 11, but all sessions continued to work normally for several days afterward (TTS-Ebook received a response as late as August 13, Web2Epub on August 10). The sessions appear to have gotten stuck during routine use around August 15–17, with no obvious trigger.

Steps to Reproduce

Start opencode server and use it for several days across multiple sessions
Sessions work normally across multiple sessions and days
At some point during normal use, certain sessions silently become unresponsive
New sessions work normally, but affected sessions cannot accept new messages
Sending messages via CLI (opencode run --session <id> --attach) produces no output
Sending messages via API POST returns HTML (web UI) instead of processing
Full system reboot does not resolve the issue
Killing and restarting the opencode server process does not resolve the issue

Investigation Findings

Database state

Sessions are present in the session table with normal metadata
No metadata field set (null) — no explicit "busy" flag
session_input table has 0 pending entries for affected sessions
session_message table has entries (model-switched, agent-switched) but no user messages after the stuck point
Events in the event table show normal session.updated.1 as the last event type
No locks in ~/.local/state/opencode/locks/ (directory is empty)

Token counts (possible factor?)

TTS-Ebook: 3M input + 260K output + 419K reasoning tokens
Web2Epub: 8.2M input + 615K output + 887K reasoning tokens
Local machine and NAS: 4.5M input + 120K output + 99K reasoning tokens

What does NOT fix it

Full system reboot (confirmed — user rebooted entire Linux box)
Restarting opencode server process (kill + restart)
Setting time_compacting on affected sessions in database
Setting time_updated to current timestamp in database

What works

opencode export <session_id> reads the full session data from the database — data is not lost
New sessions work normally
The API can list sessions (GET /api/session) — stuck sessions appear in the list
The API can read messages from stuck sessions (GET /api/session/<id>/message)

Workaround

Export the stuck sessions before they become unrecoverable:

opencode export <session_id> > session-backup.json

Then start fresh sessions and reference the exported file for context:

"Read /path/to/session-backup.json for context on this project"

Suggested Fixes

Add a per-session timeout — if a session has been "busy" for >N hours with no active process, automatically reset its state on server startup
Persist a "crashed" flag — when the server shuts down ungracefully, mark affected sessions so they can be recovered on next startup
Add a CLI command to force-reset a stuck session: opencode session reset <session_id>
The compact endpoint (POST /api/session/<id>/compact) returns "not available yet" — implementing this would provide a recovery path

Logs

The opencode log at ~/.local/share/opencode/log/opencode.log shows normal activity for affected sessions up to the point they got stuck, then no further entries related to those sessions. No error messages or timeout warnings are logged.

This issue might be a duplicate of existing issues. Please check:

opencode-session-corruption #38436: Session enters a "write-only" state where new messages are saved but AI responses are never triggered — persists across restarts, requires forking the session to recover. Very similar symptom of sessions becoming permanently unresponsive during normal use.
GET /session/status can report a session busy for a short window (and occasionally indefinitely) after its prompt stream has already closed #35472: GET /session/status can report a session busy indefinitely after its prompt stream has already closed — documents the server-side mechanism by which sessions can get permanently stuck in a busy state with no recovery path.
CLI process internal timer/location-services scheduler stops firing after ~12-15 hours of uptime, making sessions unresponsive #34372: CLI process internal scheduler stops firing after ~12–15 hours of uptime, making sessions unresponsive — covers the long-running-server angle where sessions silently stop processing new messages.
stuck in busy forever after toolcall #40468: Session stuck in busy forever after a tool call, requiring a full restart to recover.

Your report has a distinct and valuable angle — the stuck state survives full system reboots, which points to a durable/database-level issue rather than an in-memory state problem. That detail (combined with the thorough DB investigation showing no pending session_input rows and no lock files) makes this worth tracking separately even if the root cause overlaps with the above.

The absence of locks and any pending session_input is a good clue, it points to the stuck state riding on the session row itself rather than a queued message, so dumping every column on those three ids is worth a look. Also at 776MB with a couple multi-million-token contexts, a wedged WAL can silently hold the table, a PRAGMA wal_checkpoint or VACUUM on a copy often clears it. The opencode export route is the right call to protect the data meanwhile.

Additional stuck session (Aug 22)

Another session stuck, same pattern — no lock files, no pending inputs, session visible in API but refuses to process new messages.

Field	Value
Session ID	`ses_fd681eba8ffeYeWKfmV9veW8Yy`
Title	Web2Ebook - Linux
Model	mimo-v2.5-free (opencode provider)
Created	2026-08-22 12:42 UTC
Last assistant response	2026-08-22 19:01 UTC
Last user message	2026-08-22 20:01 UTC (content: `status?`)
Messages	~70
Tokens	219K input + 32K output + 1.4K reasoning

This session was created after the previous three stuck sessions (which were from Aug 8–13). It worked normally for ~8 hours on Aug 22, then got stuck. Same behavior: no error logged, no recovery on reboot, data is intact but session won't accept new messages.

This suggests the issue is not related to long-running sessions or high token counts — this session had modest usage and still got stuck within the same day.

Update: Attempted database fix made things worse

I tried to unstick the session by editing the database directly:

Found a tool call stuck in "status": "running" state
Changed it to "status": "completed" and added a fake output
Restarted the server

Result: Session became corrupted. Now returns "Invalid prompt: The messages do not match the ModelMessage[] schema" on every new message.

The stuck tool call was:

{
  "type": "tool",
  "tool": "bash",
  "state": {
    "status": "running",
    "input": {
      "command": "chmod +x /home/dwc/Desktop/web2ebook/start.sh ...",
      "timeout": 10000
    }
  }
}

Lesson learned: Direct database edits break the session schema validation. The fix needs to happen in opencode's code, not in the database.

This suggests the root cause is: when a tool call gets stuck in "running" state (e.g. process crashes or times out), opencode has no recovery path and the session becomes permanently broken.

Additional stuck session (Aug 25)

Same pattern — bash tool call stuck in "status": "running" state.

Field	Value
Session ID	`ses_fd44430f8ffetvFGC7uzp4xFBe`
Title	Web2Ebook- Linux - new
Model	mimo-v2.5-free (opencode provider)
Created	2026-08-22 23:08 UTC
Last assistant response	2026-08-25 19:08 UTC
Last user message	2026-08-25 20:48 UTC
Messages	363
Stuck tool call	bash tool, `"status": "running"`, no completion

Note: This is the replacement session after the previous one (ses_fd681eba8ffeYeWKfmV9veW8Yy) got stuck and was corrupted by my attempted database fix. The new session also got stuck within ~45 hours of creation.

Pattern is consistent: sessions get stuck when a bash tool call crashes or times out mid-execution. No recovery path exists — the session becomes permanently unusable.

New stuck pattern: session ignores user messages entirely

Different from the previous stuck sessions (which had stuck tool calls). This session shows no stuck tool calls, no errors, but completely ignores user messages.

Field	Value
Session ID	`ses_105f90312ffeY73bBj0zI9sVOY`
Title	RemoteFix
Model	mimo-v2.5-free (opencode provider, variant: high)
Created	2026-06-24
Last assistant response	2026-08-30 19:28 UTC
Last user message	2026-08-30 19:17 UTC (never processed)
Messages	503
Stuck tool calls	0

Behavior

User sent a message at 19:17 UTC
Session did not respond
No tool calls stuck in "running" state
No errors logged
No pending inputs in session_input table
Session time_updated did not change
Server restart did not help
Message was never picked up by the model

Database state

session_input: empty (0 pending)
session_message: only has model-switched/agent-switched entries, no user messages after the stuck point
event table: last event is session.updated.1 from the model switch
No locks in ~/.local/state/opencode/locks/

Summary of all stuck patterns observed

Tool call stuck in "running" state — bash command crashes/times out mid-execution, session becomes permanently unusable (3 sessions)
Session ignores user messages — no stuck tool calls, no errors, but message is never processed (this session)

Both patterns have no recovery path other than starting a new session.

Additional stuck session: Research Reports

Same pattern as RemoteFix — session ignores user messages, no stuck tool calls.

Field	Value
Session ID	`ses_0ea4144aeffe45blZXcAQ0w78O`
Title	Research Reports
Model	mimo-v2.5-free (opencode provider, variant: default)
Created	2026-06-29
Last assistant response	2026-07-02
Last user message	2026-08-31 15:37 UTC (never processed)
Messages	503

Pattern across all stuck sessions

Sessions affected:

ses_08513899fffe1yQ0ScYtryRBXN (old TTS-Ebook) — stuck Aug 17, tool call stuck
ses_0bc91dc31ffeBCZdqPJ2s02vYY (old Web2Epub) — stuck Aug 17, tool call stuck
ses_1494d504dffeekKczywChTegQc (old Local machine and NAS) — stuck Aug 17, tool call stuck
ses_fd681eba8ffeYeWKfmV9veW8Yy (old Web2Ebook - Linux) — stuck Aug 22, tool call stuck
ses_fd44430f8ffetvFGC7uzp4xFBe (Web2Ebook- Linux - new) — stuck multiple times, tool call stuck
ses_105f90312ffeY73bBj0zI9sVOY (RemoteFix) — stuck Aug 30, message ignored
ses_0ea4144aeffe45blZXcAQ0w78O (Research Reports) — stuck Aug 31, message ignored

Key observations:

All sessions use mimo-v2.5-free or deepseek-v4-flash-free
Sessions compacted on Aug 18 are stuck (3 sessions)
Sessions that were working Aug 30 are now stuck (RemoteFix, Research Reports)
Two distinct failure modes: (a) tool call stuck in "running" state, (b) session ignores user messages entirely
Both modes have no recovery path
Server restarts do not fix either mode
The opencode binary has not been updated (last modified Jun 10)

Log evidence

RemoteFix session shows "loop" and "exiting loop" events — opencode tried to process it but exited immediately without sending the message to the model:

timestamp=2026-08-30T19:17:37.639Z level=INFO run=b8928288 message="exiting loop" session.id=ses_105f90312ffeY73bBj0zI9sVOY

This suggests the session enters a state where opencode detects it needs processing, starts a loop, but immediately exits without completing the work.

Workaround found for stuck tool calls

The "tool call stuck in running" pattern has a root cause and a fix.

Root cause

A bash script used exec to start a daemon:

exec /path/to/daemon.py

exec replaces the shell process with the daemon. Since opencode's bash tool waits for the command to complete, and the daemon runs forever, the bash tool hangs forever. The session becomes permanently stuck.

Fix

Replace exec with background execution:

/path/to/daemon.py &
disown
sleep 1

This runs the daemon in the background and detaches it, so the bash tool exits cleanly.

Verification

After applying this fix:

The daemon starts successfully
The bash tool completes without hanging
The session continues to work normally
No stuck tool calls

Suggestion for opencode

Consider adding a timeout to bash tool execution, or detecting when a command uses exec and warning the user that it may cause the session to hang.

Update: Fix for exec not fully resolved

After fixing the exec issue in start.sh (replacing with & and disown), the command still gets flagged as stuck by opencode's bash tool.

What was fixed

# Before (causes hang):
exec /path/to/daemon.py

# After (should exit cleanly):
/path/to/daemon.py &
disown

What still happens

The command:

kill $(cat /tmp/web2ebook.pid) 2>/dev/null; sleep 1; cd /home/dwc/Desktop/web2ebook && ./start.sh

Completes successfully when run manually or with timeout
The daemon starts and runs correctly
But opencode's bash tool still marks it as stuck in "running" state

Possible causes

Background process detection — opencode may be tracking child processes and not properly detecting when a backgrounded daemon exits the process tree
Shell cleanup — when the bash tool's shell exits, it may be waiting for all child processes to complete, including the backgrounded daemon
Process group issues — the daemon may be inheriting the shell's process group, causing the shell to wait for it

Suggestion

The bash tool should either:

Use setsid to create a new process group for background commands
Have a configurable timeout for all bash commands
Detect when a command's purpose is to start a daemon and handle it differently
Not track background processes started with & and disown

New stuck pattern: glob tool stuck in running state

A third stuck pattern has been observed — the glob tool (file pattern matching) stuck in "status": "running" state.

Field	Value
Session ID	`ses_fac65f4ebffe8AZ7nFgr3oPkVs`
Title	Custom Linux
Model	mimo-v2.5-free (opencode provider)
Created	2026-08-30
Stuck tool	`glob` (file pattern matching)

Behavior

Glob tool stuck in "running" state
Session stops responding to new messages
No stuck bash tool calls (different from previous patterns)
Session had no permission issues — file was readable and NAS was responsive

Fix attempted

Deleted the stuck glob part from the database. Session structure was not corrupted (unlike previous bash tool fix attempts).

Updated summary of stuck patterns

Bash tool stuck in "running" state — exec in scripts causes bash tool to hang forever (3+ sessions)
Session ignores user messages — no stuck tool calls, no errors, message never processed (2+ sessions)
Glob tool stuck in "running" state — file pattern matching hangs, session becomes unresponsive (1 session)

All three patterns have no automatic recovery and require either server restart or database intervention.

Custom Linux session also stuck ("session ignores user messages" pattern)

The Custom Linux session (ses_fac65f4ebffe8AZ7nFgr3oPkVs) is now stuck with the second pattern.

Timeline

Session had a stuck glob tool call
Deleted the stuck glob part from database
Session structure was valid, no schema corruption
User sent new messages — none were processed
No stuck tool calls, no pending inputs, no errors
Session just ignores all user messages

Updated pattern count

Bash tool stuck — 3+ sessions (fixed by changing exec to & and disown)
Session ignores user messages — 3+ sessions (RemoteFix, Research Reports, Custom Linux)
Glob tool stuck — 1 session (Custom Linux, resolved by deleting stuck part, but session still unresponsive)

The glob tool issue may be a trigger for the "session ignores messages" pattern — once the session gets into a bad state from a stuck tool, it never recovers even after the stuck tool is removed.

Update: Completed bash commands stuck in "running" state

Additional finding — commands that completed successfully are still shown as "running" by the bash tool.

Evidence

This session (`ses_fed9937acffevoWSMgWVkObvfJ") has 6 stuck bash tool calls, all of which were completed by the agent during this conversation:

kill -9 1090 — server restart attempt (completed)
pkill -f "opencode web" — server restart attempt (completed)
3-6. Multiple restart and database check commands (all completed)

All commands produced output and the session continued working. But the bash tool still shows them as "running".

Key insight

This is not just about exec or background processes. Any bash command can get stuck in "running" state after completion. The bash tool's completion detection is broken.

Impact

UI shows "Running command..." indefinitely
Session continues to work (can send/receive messages)
But the stuck tool state may eventually cause the session to become unresponsive
This happened in the session currently being used to document this bug

Affected interface

User is using OC Remote interface app. May be relevant to how the interface detects command completion.

Update: Custom Linux session stuck again

Same session (ses_fac65f4ebffe8AZ7nFgr3oPkVs), third time stuck.

Pattern confirmed

Bash tool shows command as "running" after completion
Session stops responding to user messages
Deleting the stuck part from the database restores responsiveness

Workaround

Run this to delete stuck parts:

import sqlite3, json
session_id = "<stuck_session_id>"
db_path = "/home/dwc/.local/share/opencode/opencode.db"
conn = sqlite3.connect(db_path)
c = conn.cursor()
c.execute("SELECT id, data FROM part WHERE session_id = ?", (session_id,))
for pid, pdata in c.fetchall():
    pd = json.loads(pdata)
    if pd.get("type") == "tool" and pd.get("state", {}).get("status") == "running":
        c.execute("DELETE FROM part WHERE id = ?", (pid,))
conn.commit()
conn.close()

Then restart the opencode server.

Note

This workaround only works if the session hasn't been corrupted by previous edits. If it returns "messages do not match ModelMessage[] schema", the session is permanently broken.

Critical: Restarting opencode via bash tool requires full CPU reboot

Problem

When the agent tries to restart the opencode web server using the bash tool:

pkill -f "opencode web --hostname 0.0.0.0" && sleep 2 && /home/dwc/.opencode/bin/opencode web --hostname 0.0.0.0 &

The command completes but opencode becomes unresponsive. A full CPU reboot is required to recover.

Reproduction

Agent runs the restart command via bash tool
Command appears to complete
opencode stops responding to all sessions
Server restart does not fix it
Only a full CPU reboot recovers the system

Affected sessions

This has happened multiple times during this conversation
Requires user to physically reboot their machine each time

Impact

User loses all active session state
Productive work is interrupted
User must manually restart their computer

Suggestion

opencode should:

Never allow the agent to restart the server it is running on
Add a safety check that prevents killing the parent process
Document that server restarts must be done manually by the user
Consider a "server restart" button in the UI instead of bash commands

New stuck pattern: question and task tools

A fourth stuck pattern — the question and task tools stuck in "running" state.

Field	Value
Session ID	`ses_0df853b59ffe9fM31areg77Qr1`
Title	ARYA
Created	2026-07-02
Stuck tools	`question` tool and `task` tool

Behavior

Both tools stuck in "running" state
Session stops responding to user messages
No stuck bash or glob calls (different from previous patterns)

Fix

Deleted the stuck parts from the database. Session became responsive again.

Updated pattern count

Bash tool stuck — multiple sessions (fixed by deleting stuck parts or changing exec to &)
Session ignores user messages — multiple sessions (no stuck tools, just no response)
Glob tool stuck — 1 session (fixed by deleting stuck part)
Question/task tools stuck — 1 session (fixed by deleting stuck parts)

Key finding

Any tool type can get stuck in "running" state — bash, glob, question, task. The issue is not tool-specific. The bash tool's completion detection is broken across all tool types.

Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

Sessions permanently stuck during normal use — survive reboots, cannot be recovered #43277

Description

Sessions permanently stuck during normal use — survive reboots, cannot be recovered

Description

Environment

Affected Sessions

Steps to Reproduce

Investigation Findings

Database state

Token counts (possible factor?)

What does NOT fix it

What works

Workaround

Suggested Fixes

Logs

Activity

github-actions commented on Aug 18, 2026

MilkyWay008 commented on Aug 18, 2026

dcon4 commented on Aug 22, 2026

Additional stuck session (Aug 22)

dcon4 commented on Aug 22, 2026

Update: Attempted database fix made things worse

dcon4 commented on Aug 25, 2026

Additional stuck session (Aug 25)

dcon4 commented on Aug 30, 2026

New stuck pattern: session ignores user messages entirely

Behavior

Database state

Summary of all stuck patterns observed

dcon4 commented on Aug 31, 2026

Additional stuck session: Research Reports

Pattern across all stuck sessions

Log evidence

dcon4 commented on Sep 7, 2026

Workaround found for stuck tool calls

Root cause

Fix

Verification

Suggestion for opencode

dcon4 commented on Sep 10, 2026

Update: Fix for exec not fully resolved

What was fixed

What still happens

Possible causes

Suggestion

dcon4 commented on Sep 13, 2026

New stuck pattern: glob tool stuck in running state

Behavior

Fix attempted

Updated summary of stuck patterns

dcon4 commented on Sep 13, 2026

Custom Linux session also stuck ("session ignores user messages" pattern)

Timeline

Updated pattern count

dcon4 commented on Sep 13, 2026

Update: Completed bash commands stuck in "running" state

Evidence

Key insight

Impact

Affected interface

dcon4 commented on Sep 13, 2026

Update: Custom Linux session stuck again

Pattern confirmed

Workaround

Note

dcon4 commented on Sep 13, 2026

Critical: Restarting opencode via bash tool requires full CPU reboot

Problem

Reproduction

Affected sessions

Impact

Suggestion

dcon4 commented on Sep 17, 2026

New stuck pattern: question and task tools

Behavior

Fix

Updated pattern count

Key finding

thdxr commented on Oct 11, 2026

Metadata