Repository navigation
Standing server prompt POST hangs: session created, prompt never progresses (127.0.0.1:13420) #857
Description
Problem
The standing laptop OpenCode server on 127.0.0.1:13420 accepts session creation but its prompt POST never progresses: observed hanging for over 15 minutes producing nothing. This is a server-side stall, not a provider failure — no error is returned and no output is produced.
Evidence (OpenClaw-vs-OpenCode comparison, 2026-10-29 early morning CDT, tracked on developing-today/code#2171)
During setup of the five-fixture comparison, two OpenCode surfaces were tried and found non-viable:
opencode run(CLI) blocks indefinitely without creating a session (two attempts killed) — already tracked in opencode run (CLI) hangs after init on headless Linux — investigate #193.- The standing server on 127.0.0.1:13420 accepted a session, but its prompt POST hung >15 min producing nothing. One F1 prompt POST died with that server; the fixture was then executed once, to completion, on the working route.
Workaround used for the whole comparison: the OpenChamber-managed OpenCode instance on 127.0.0.1:36183, agent build, route opencode-route/workhorse — all five fixtures completed there. So the same binary/config family serves prompts fine via the managed instance while the standing server's prompt route stalls.
Impact
This blocks the fleet's standard session route: any session driven through the standing server's prompt POST stalls silently. All comparison work had to be routed around it to the managed instance. A stall with no error and no output is also invisible to callers — there is nothing to retry against.
What to investigate
- What the standing server's prompt POST path waits on after session creation that the managed instance's path does not (event subscription, watcher, session attach, directory scope handling).
- Whether the stall reproduces with a fresh session on the same server today, and whether server logs show the prompt request arriving at all.
- Whether a prompt timeout / progress signal is owed so a stalled prompt surfaces as an error instead of hanging forever.
Acceptance
- Root cause identified and fixed, or a documented workaround with the blocking component named.
- A prompt POST to the standing server completes (or fails loudly) instead of hanging >15 min.
Acceptance criteria
- The hang is reproduced against the standing server on 127.0.0.1:13420 (session created, prompt POST stalls) and the stall point is identified (server log / stack evidence linked here) — or the server is shown healthy under the same repro and the issue is closed with that evidence.
- A prompt POST to the standing server completes (or errors visibly) within a bounded time in a verification run; indefinite silent hangs are the failure being closed.
- The relationship to the CLI-surface hang in opencode run (CLI) hangs after init on headless Linux — investigate #193 is stated: same root cause, or explicitly different.
Activity
developing-today commentedon Oct 29, 2026
OPENCODE-201
dezren39 commentedon Oct 29, 2026
Intake review
status/needs-triage,effort/m,meta/enrichedadded.opencode runCLI hang — possibly the same stall one surface over), OpenClaw: finish setup, begin passing jobs, and review results against OpenCode developing-today/code#2171 (the comparison whose setup found this), openchamber feat(plugin): expose child session listing and server URL to v2 plugins #766 (one standing server + one session store).dezren39 commentedon Oct 30, 2026
agent-note:v1
state: picked up
Agent: issue sweep (issue-sweep-rotating)
Session/ID: issue-sweep-rotating run 2026-10-29 20:24 CDT
Found via: sweep pickup
Task: Triage #857 — time-boxed fresh-session reproduction against the standing laptop server on 127.0.0.1:13420, record whether the prompt POST still stalls today.
Expectation: effort/m — done looks like a dated reproduction verdict (still stalls / no longer stalls / cannot test, with the blocker) posted on this issue.
dezren39 commentedon Oct 30, 2026
agent-note:v1
state: blocked (triage complete)
Agent: issue sweep (issue-sweep-rotating)
Session/ID: issue-sweep-rotating run 2026-10-29 20:24 CDT
Triage verdict 2026-10-29 evening — the surface changed; the original hang no longer reproduces as-is
Probed the standing laptop server on 127.0.0.1:13420 directly (laptop SSH, read-only curl):
opencode serve --service, build 2.0.30+ad881d2 (nix store), up ~15h at probe time.GET /global/health,/session,/config,/docall return 200 text/html (the SPA), andPOST /sessionreturns 405 with an empty body — session creation is no longer accepted on that path at all (previously it was accepted and the prompt POST then hung)./api/*and requires authentication:GET /api/sessionandGET /api/global/healthreturn 401 application/jsonUnauthorizedError, andPOST /api/sessionlikewise 401.What this means
/api/*+ auth surface.Labels reset: self-assignment released, marked status/blocked.
dezren39 commentedon Oct 30, 2026
Unblocked fleet-side — this does NOT need Drew. Retest from the main chat (2026-10-29 ~20:33 CDT) using the standing fleet pattern: the server credential was read from ~/.local/state/opencode/service-prod.json inside a laptop-side command only (value never printed or collected anywhere), Basic auth as opencode:, header x-opencode-directory: /home/user.
Evidence on the standing server (127.0.0.1:13420, opencode 2.0.30, v2 API):
The v1 surface the original hang was filed against is gone in 2.0.30 (POST /session -> 405, SPA HTML on v1 paths); the supported surface is /api/*. The prompt-POST hang should be considered not-reproducing on the current build — if it recurs, it needs a fresh report against the v2 routes with timings. Removing the blocked-on-Drew framing: no credential needs to be supplied by Drew; the approved channel already exists and was used here. This also clears #857 as a hard prerequisite for openchamber#766 on current evidence.
developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 7048 (triage, queued, priority 50) in repo-health-opencode-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03
dezren39 commentedon Nov 4, 2026
Triage (task 7048) — fresh verification run 2026-11-04 against the standing server (127.0.0.1:13420, current build, credential read only inside a laptop-side command from
~/.local/state/opencode/service-prod.json, never printed):GET /api/session→ 200 with the live session list (auth + v2 API healthy;/api/global/healthnow 404s — the health path moved, the API did not).POST /api/session{model: opencode-route/speed as a Model.Ref} → 200, sessionses_e5e5b2c44e9ffeaS4oWefmzraFcreated.POST /api/session/{id}/prompt{"Reply with the single word: ok"} → 200 in under a second; the turn progressed observably (assistant message created immediately, retry state visible) and settled to a visible terminal error in ~2 minutes:provider.quota— "Go usage limit exceeded" (429 from the route's Go provider), recorded on the assistant message after 11 attempts.Verdict: the #857 hang does not reproduce. The v1 surface it was filed against is gone (2.0.30+), and on the current build the prompt route answers immediately, exposes progress, and fails loudly with a named provider error instead of stalling silently for >15 minutes. This matches the 2026-10-29 main-chat retest (prompt 200 in ~1s, turn settled with usage) and satisfies the acceptance branch "the server is shown healthy under the same repro and the issue is closed with that evidence" — the server side is healthy; today's turn failure is a provider quota wall on one route, which is quota-management territory (sibling #431 family), not a server stall. Closing. If a silent stall recurs on the v2 routes, file a fresh report with timings.