`serve` 1.18.25: `GET /api/session/<id>/message` returns `{"data":[]}` for every session (Desktop shows empty transcript)

serve 1.18.25: GET /api/session/<id>/message returns {"data":[]} for every session (Desktop shows empty transcript)

Summary

OpenCode Desktop (Windows, v1.18.25) connected to a remote opencode serve (v1.18.25, Linux) lists sessions correctly but the message transcript is always empty. Server log shows the desktop's message fetch being rejected, and — critically — the message endpoint returns empty even with a valid limit, for sessions that provably contain thousands of messages in SQLite.

Environment

• Server: opencode serve --hostname 0.0.0.0 --port 4096 on Ubuntu 24.04, opencode 1.18.25 (linux-x64, curl install).
• Client: OpenCode Desktop 1.18.25 on Windows 11 (Tailscale, remote server). Also reproducible with plain curl against the server.
• DB: default ~/.local/share/opencode/opencode.db (event-sourcing SQLite), checked read-only.

Reproduction (server-side, no client needed)

Session ses_ff916117... has 3755 rows in message and 18943 rows in part (verified via sqlite3 read-only). Direct request:

curl -s 'http://127.0.0.1:4096/api/session/ses_ff916117affeXDB0eIf5n9jFKD/message?limit=200&order=desc'
{"data":[],"cursor":{"previous":null,"next":null}}   # 200 OK, empty
curl -s 'http://127.0.0.1:4096/api/session/ses_ff916117affeXDB0eIf5n9jFKD/message?limit=200&order=asc'
{"data":[],"cursor":{"previous":null,"next":null}}   # 200 OK, empty
curl -s 'http://127.0.0.1:4096/api/session?limit=200&order=desc'
{"data":[{...session metadata...},...]}              # list endpoint works, sessions visible

Empty data is returned for every session, including sessions created minutes earlier by this same 1.18.25 server process (e.g. ses_fb0c7d..., today) — so it is not a legacy/row-format issue. opencode export <sessionID> reads the same DB and yields the full transcript (40 MB JSON), so data integrity is fine; only the /api/session/<id>/message path is affected.

Secondary mismatch observed

The desktop's initial list fetch uses limit=5000 and its refresh path uses limit=0; both are rejected by the server schema (limit must be 1–200):

level=WARN message="schema rejection" kind=Query
  reason="Expected a value greater than or equal to 1, got 0\n  at [\"limit\"]"
level=WARN message="schema rejection" kind=Query
  reason="Expected a value less than or equal to 200, got 5000\n  at [\"limit\"]"

Even if the client sent a valid limit, the endpoint would still return empty data (see reproduction above).

Expected behavior

GET /api/session/<id>/message?limit=..&order=.. should return the stored messages for an existing session (paged), so remote Desktop clients can render the transcript.

Related

• #42267 — desktop sends limit=0 on message fetch (client side of the same feature gap).
• #38470 — sessions created via POST /api/session on serve missing MCP tools (another /api + serve gap).
• #42266 — desktop sidecar API 500s (related /api instability on the serve/desktop path).

Notes / reproducibility quick-check on any server

SID=$(curl -s 'http://127.0.0.1:4096/api/session?limit=50&order=desc' | jq -r '.data[0].id')
curl -s "http://127.0.0.1:4096/api/session/$SID/message?limit=200&order=desc"
# → {"data":[],"cursor":{"previous":null,"next":null}} despite messages existing in the DB