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.

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:

1. Found a tool call stuck in "status": "running" state
2. Changed it to "status": "completed" and added a fake output
3. 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.

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.

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

1. Tool call stuck in "running" state — bash command crashes/times out mid-execution, session becomes permanently unusable (3 sessions)
2. 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.

Pattern across all stuck sessions

Sessions affected:

1. ses_08513899fffe1yQ0ScYtryRBXN (old TTS-Ebook) — stuck Aug 17, tool call stuck
2. ses_0bc91dc31ffeBCZdqPJ2s02vYY (old Web2Epub) — stuck Aug 17, tool call stuck
3. ses_1494d504dffeekKczywChTegQc (old Local machine and NAS) — stuck Aug 17, tool call stuck
4. ses_fd681eba8ffeYeWKfmV9veW8Yy (old Web2Ebook - Linux) — stuck Aug 22, tool call stuck
5. ses_fd44430f8ffetvFGC7uzp4xFBe (Web2Ebook- Linux - new) — stuck multiple times, tool call stuck
6. ses_105f90312ffeY73bBj0zI9sVOY (RemoteFix) — stuck Aug 30, message ignored
7. 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

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

Possible causes

1. Background process detection — opencode may be tracking child processes and not properly detecting when a backgrounded daemon exits the process tree
2. Shell cleanup — when the bash tool's shell exits, it may be waiting for all child processes to complete, including the backgrounded daemon
3. 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.

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

1. Bash tool stuck in "running" state — exec in scripts causes bash tool to hang forever (3+ sessions)
2. Session ignores user messages — no stuck tool calls, no errors, message never processed (2+ sessions)
3. 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

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

Updated pattern count

1. Bash tool stuck — 3+ sessions (fixed by changing exec to & and disown)
2. Session ignores user messages — 3+ sessions (RemoteFix, Research Reports, Custom Linux)
3. 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:

1. kill -9 1090 — server restart attempt (completed)
2. 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

1. Bash tool shows command as "running" after completion
2. Session stops responding to user messages
3. 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

1. Agent runs the restart command via bash tool
2. Command appears to complete
3. opencode stops responding to all sessions
4. Server restart does not fix it
5. 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:

1. Never allow the agent to restart the server it is running on
2. Add a safety check that prevents killing the parent process
3. Document that server restarts must be done manually by the user
4. 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.

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

1. Bash tool stuck — multiple sessions (fixed by deleting stuck parts or changing exec to &)
2. Session ignores user messages — multiple sessions (no stuck tools, just no response)
3. Glob tool stuck — 1 session (fixed by deleting stuck part)
4. 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.