/session/status potentially not reporting properly

[GrahamJenkins]

Plugins

None

OpenCode version

1.1.53

Steps to reproduce

No response

Screenshot and/or share link

n/a

Operating System

Fedora 43

Terminal

Bash

Description

I have been using opencode to create a wrapper for opencode (integrating into a tool I'm building) and was attempting to use event based processing of data in sessions, since generating can take a fair amount of time. (and running async was experiencing timeouts). I tested multiple approaches and the determination of claude sonnet 4.5 is that the /session/status is not returning values that align with the documentation. I had it write some test scripts which appear to confirm this.

System Information:
OpenCode 1.1.53
Development/diagnosis done within OpenCode
Running opencode serve
Opencode error:

                                       ^
TypeError: undefined is not an object (evaluating 'agent.model')
      at createUserMessage (src/session/prompt.ts:830:34)

825 |   }
826 |
827 |   async function createUserMessage(input: PromptInput) {
828 |     const agent = await Agent.get(input.agent ?? (await Agent.defaultAgent()))
829 |
830 |     const model = input.model ?? agent.model ?? (await lastModel(input.sessionID))
                                       ^
TypeError: undefined is not an object (evaluating 'agent.model')
      at createUserMessage (src/session/prompt.ts:830:34)

I'm not sure if the error above is related to what is described below, disregard it if it is not relevant.

Following is my AI agent's summary of the perceived bug. I can't personally guarantee that this is accurate, but it seems plausible and I haven't found any other resolutions.

--------- End User Generated Content -----------

(AI-Generated) Bug Report: OpenCode Server Loses Track of Asynchronous Sessions

Summary

When a client sends an asynchronous command to the OpenCode server (via the /session/{session_id}/prompt_async endpoint), the server appears to lose track of the session's state. The session's status is not correctly reported via the /session/status endpoint, and subsequent synchronous commands to the same session fail to execute correctly. This prevents clients that rely on the server's event and status system from working as expected.

Steps to Reproduce

1. Create a new session: Send a POST request to /session to create a new session.
2. Send an asynchronous command: Send a POST request to /session/{session_id}/prompt_async with a command to execute (e.g., git status).
3. Poll for session status: Periodically send GET requests to /session/status to check the status of the created session.
4. Send a synchronous command: After a short period, send a POST request to /session/{session_id}/message with a new command.

Expected Behavior

• After the asynchronous command is sent, the session status reported by /session/status should be streaming or a similar active state, and eventually transition to idle once the command is complete.
• The server should emit a session.status_changed event via its Server-Sent Events (SSE) stream, indicating the transition to idle.
• Subsequent synchronous commands to the session should execute correctly and return the command's output.

Actual Behavior

• The status of the session, as reported by /session/status, remains unknown indefinitely. The server never reports the session as streaming or idle.
• No session.status_changed event is ever received for the session.
• Subsequent synchronous commands sent to the session return an immediate, empty response instead of executing and returning the command's output.

Evidence

The following is the output of a test script that automates the reproduction steps:

'''
Creating session '''Bug Reproduction Test'''...
-> Session created with ID: ses_3c4d71dd0ffekqdJDOmP4F2CbK

Sending async command: '''git status'''
-> Async prompt sent (status: 204)

Polling session status every 2s for 30s...
[0.0s] Current status: '''unknown'''
[2.0s] Current status: '''unknown'''
[4.0s] Current status: '''unknown'''
[6.0s] Current status: '''unknown'''
[8.0s] Current status: '''unknown'''
[10.0s] Current status: '''unknown'''
[12.0s] Current status: '''unknown'''
[14.0s] Current status: '''unknown'''
[16.0s] Current status: '''unknown'''
[18.0s] Current status: '''unknown'''
[20.0s] Current status: '''unknown'''
[22.0s] Current status: '''unknown'''
[24.0s] Current status: '''unknown'''
[26.0s] Current status: '''unknown'''
[28.0s] Current status: '''unknown'''

Polling timed out. Session did not become idle.
-> Final status after timeout: '''unknown'''
-> CONFIRMED: Server lost track of the session status.

Attempting to send sync command: '''echo 'hello'''' (expecting a timeout)
-> Received a response unexpectedly:

--- Test Summary ---
The test successfully reproduced the bug.

1. An async command was sent.
2. The server lost track of the session's status, which remained 'unknown'.
3. A subsequent synchronous command to the same session returned an immediate empty response.
   This confirms the opencode-server is not correctly handling these sessions.

[github-actions]

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

• TUI doesn't render messages from prompt_async endpoint #8564: TUI doesn't render messages from prompt_async endpoint - related to prompt_async not appearing in UI
• API doesn't report invalid model errors via event stream #8460: API doesn't report invalid model errors via event stream - related to session.error not being emitted properly
• session.error not emitted when Provider.getModel fails in main prompt loop #12738: session.error not emitted when Provider.getModel fails in main prompt loop - directly related to model handling in async operations
• fix: add missing await in prompt_async handler - CRITICAL: Empty response bug #11289: fix: add missing await in prompt_async handler - CRITICAL: Empty response bug - directly related to prompt_async handling

Feel free to ignore if none of these address your specific case.

[GrahamJenkins]

Issue #8460 does look potentially related. It could be that my API request was not including a model (I assumed it would use the system default, is that a mistake?) and this is causing an error, as seen on the server. I still feel like the /session/status should return an error rather than "unknown". My suspicion is that this may be indirectly affected, but isn't fully covered by the linked issue.