Sharing & headless

You’re three days into feedmill and stuck on a single feed. One source’s Atom export almost-but-not-quite parses — dates land an hour off, a handful of entries dedupe against the wrong key — and you’ve spent forty minutes in one session reading parser code, trying fixes, and watching OpenCode talk itself in circles. This is the moment you’d normally paste a wall of terminal output into a chat with a colleague and hope they can follow it. OpenCode gives you something better, and it gives you something the closed tools don’t: you can hand someone the whole session as a URL.

That’s the first half of this chapter. /share turns the session you’re standing in — the prompts, the reasoning, the diffs, the dead ends — into a public link at opncd.ai/s/<id> that anyone can open and read in a browser, no OpenCode install required. No closed agent hands you that. And the moment a corporate engineer hears “public link to my session,” the next thought is the right one: what exactly leaves the building when I do that? So the first lesson is as much about governance as it is about the feature — the manual/auto/disabled sharing modes, what’s in the payload, and how to make sure a feedmill session full of internal feed URLs doesn’t become a feedmill session on the open web by accident.

The second half is where OpenCode’s client/server architecture stops being trivia and starts paying rent. The same engine behind the TUI can be driven with no TUI at all: opencode run takes a prompt, does the work, and prints a result — and with --format json, prints it in a shape a script can act on. opencode serve stands that engine up as a long-running HTTP server you can point automation at. Put those together and feedmill — a thing already built to run unattended on a cron — gets an agent that can run unattended too: nightly checks, CI gates, and issues you triage straight from GitHub.

Three moves, in order:

• Share a session, and govern what leaves — take the stuck parser session, share it for a second opinion, and lock down exactly what’s allowed to leave with it — Share a session, and govern what leaves
• Run OpenCode headless — drive the same parser fix as a non-interactive opencode run with JSON output, the way a script or a teammate’s pipeline would — Run OpenCode headless
• The server, CI, and GitHub — stand up opencode serve, wire feedmill’s checks into CI against its own server, and act on issues through first-class GitHub integration — The server, CI, and GitHub

Doing these as one continuous task matters because they’re two sides of the same architecture, and the chapter only lands if you feel that. The share link and the headless run are the same session seen two ways: one opened up for a human to read, the other handed to a machine to execute. You’ll share the tricky parser session for a second opinion, then turn around and run that exact fix as a command — and somewhere in between it should click that “interactive TUI” and “automated pipeline” were never two different OpenCodes. They’re one engine you can either sit in front of or point a script at. Get fluent in moving between those two and feedmill stops being a project you babysit and becomes one that mostly runs itself, with you in the loop only when it asks.

Start by sharing the stuck session.