opencode-server-ops

Diagnose OpenCode v2 server timeouts, zombie sessions, and model registration issues via its HTTP API.

1|Updated Aug 13, 2026
One-click install
npx skills add https://github.com/corv89/hermes-stack --skill opencode-server-ops-corv89
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: opencode-server-ops
Source: https://github.com/corv89/hermes-stack/tree/main/skills/opencode-server-ops
Command: npx skills add https://github.com/corv89/hermes-stack --skill opencode-server-ops-corv89

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Debugging the OpenCode v2 coding server is hard because the blocking oc CLI hides server-side state: a client timeout does not mean the task failed, sessions can silently die while still accepting prompts, and provider outages mimic server-wide failures. This Skill provides the operational knowledge and scripts to distinguish these failure modes and recover correctly. ## Core Features & Use Cases - Zombie and wedge diagnosis: Identify dead sessions (finish=None, completed=None), server-wide execution wedges, and hanging providers using the PONG split-test probe and one-shot health check scripts. - Async dispatch and collection: Fire-and-forget task dispatch via the non-blocking POST /api/session/{sid}/prompt endpoint, with later collection through SSE-driven wait scripts that auto-approve permissions. - Model and provider troubleshooting: Fix spurious tools: false flags, register new model IDs in opencode-v2.json, and fail over between separately-billed providers (e.g. zai vs zai-coding-plan) when one is exhausted. - Use Case: A delegated coding task times out after 40 minutes. Instead of re-dispatching blindly, you run the diagnose script, discover the session is a zombie that died mid-research, and re-dispatch a fresh self-contained session pinned to a verified provider. ## Quick Start Ask the agent to run the oc_diagnose.py script against the stuck OpenCode session ID and report whether it is a zombie, a provider hang, or a server-wide wedge.

Frequently Asked Questions about opencode-server-ops

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug an OpenCode session that timed out?

A client timeout does not kill the server-side session, so first reattach with `oc --session <id>` or collect output via the oc_collect.py script. Only investigate further if the session shows no progress, such as a tool part stuck in running state for over 10 minutes.

How do I run long OpenCode tasks asynchronously without a dispatch flag?

POST to /api/session/{sid}/prompt is non-blocking, so create a session and send the prompt via the HTTP API, then exit. The oc_dispatch.py script does this and prints the session id; collect results later with oc_collect.py.

Why does my OpenCode session accept prompts but never execute them?

This is the zombie-execution signature: the newest assistant turn has finish=None and completed=None with empty permission and question queues. The session cannot be revived; abandon it and re-dispatch a fresh self-contained session.

Does the tools:false flag mean bailian models cannot use function calling?

No, the flag is a spurious config artifact. Alibaba's Qwen model families support native function calling, and SSE traces confirm tool calls work. Add capabilities with tools:true to each model entry in opencode-v2.json to fix the registry display.

How do I tell a dead provider from a wedged OpenCode server?

Run the oc_ping.py PONG probe against two different providers. If one provider responds with finish=stop and the other hangs, the provider is dead (often an exhausted token plan); only if every provider hangs is the server engine wedged and in need of a restart.

What should I do when an OpenCode provider runs out of balance?

Switch to the same model ID on the separately-billed coding-plan variant, for example zai-coding-plan instead of zai. Verify the fallback with a trivial prompt before dispatching real work, since each provider bills independently.