> headless & scripting

opencode run is opencode without the UI: it takes a prompt, runs to completion, prints the answer, and exits — the entry point for shell pipelines, git hooks, and CI. It shares the TUI's config, agents, providers, and sessions, so -c continues where you left off, -f attaches files, --format json makes the output parseable, and opencode serve exposes the whole thing over HTTP.

// headless & scripting

6 commands

// faq

How do I use opencode in a shell pipeline?

Pipe data into opencode run on stdin and give it an instruction: cat error.log | opencode run "explain this error". The prompt is the argument; stdin is appended as extra context. Add --format json when a later step needs to parse the result programmatically.

Why does each opencode run forget the previous one?

By design, every opencode run starts a brand-new session unless you tell it otherwise. Pass -c to continue the most recent session, or -s <session-id> to attach to a specific one, so a multi-step script accumulates context instead of resetting each call.

Can I run opencode without it asking for permission?

Yes — set the edit and bash permissions to "allow" or "deny" in config, or run the read-only plan agent with --agent plan. An "ask" permission in a headless run has no interactive prompt to answer and will stall or fail, so make the decision explicit for unattended jobs.

What is opencode serve for?

opencode serve runs opencode as a headless HTTP API (default port 4096) that other tools, scripts, or a remote TUI can drive; opencode web adds a browser UI. It lets you host the agent on one machine and attach from another with opencode attach, but it exposes a tool that edits files and runs shell, so require auth and do not bind it to a public interface.