anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

/session/status potentially not reporting properly #8919

New Issue
Open
opened 2026-02-16 18:11:10 -05:00 by yindo · 2 comments
yindo commented 2026-02-16 18:11:10 -05:00
Owner
Copy Link
Copy Source

Originally created by @GrahamJenkins on GitHub (Feb 9, 2026).

Originally assigned to: @thdxr on GitHub.

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.
Originally created by @GrahamJenkins on GitHub (Feb 9, 2026). Originally assigned to: @thdxr on GitHub. ### 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.
yindo added the bug label 2026-02-16 18:11:10 -05:00
yindo commented 2026-02-16 18:11:11 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Feb 9, 2026):

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

  • #8564: TUI doesn't render messages from prompt_async endpoint - related to prompt_async not appearing in UI
  • #8460: API doesn't report invalid model errors via event stream - related to session.error not being emitted properly
  • #12738: session.error not emitted when Provider.getModel fails in main prompt loop - directly related to model handling in async operations
  • #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.

@github-actions[bot] commented on GitHub (Feb 9, 2026): This issue might be a duplicate of existing issues. Please check: - #8564: TUI doesn't render messages from prompt_async endpoint - related to prompt_async not appearing in UI - #8460: API doesn't report invalid model errors via event stream - related to session.error not being emitted properly - #12738: session.error not emitted when Provider.getModel fails in main prompt loop - directly related to model handling in async operations - #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.
yindo commented 2026-02-16 18:11:11 -05:00
Author
Owner
Copy Link
Copy Source

@GrahamJenkins commented on GitHub (Feb 9, 2026):

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.

@GrahamJenkins commented on GitHub (Feb 9, 2026): 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.
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#8919
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?