Sharing & headless

Every project has a session like this one. On feedmill - the course’s illustrative Go feed aggregator - a single source’s Atom export almost-but-not-quite parses: dates land an hour off, a handful of entries dedupe against the wrong key, and the debugging session fills up with parser code, attempted fixes, and OpenCode circling. The next instinct is to paste a wall of terminal output into a chat with a colleague and hope they can follow it.

OpenCode used to offer something better: /share turned the whole session into a public opncd.ai/s/<id> link. That feature was discontinued in v1.19.1 (2026-10-15; release notes, as of October 2026), so the first lesson is now about what to do instead and about what still leaves your machine when you work on proprietary code: the question “what exactly leaves the building?” outlived the feature.

The second half is where OpenCode’s client/server architecture stops being trivia and starts paying rent. The same engine behind the TUI (terminal user interface) 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 as a stream of JSON events a script can act on (as of October 2026; CLI documentation). opencode serve stands that engine up as a long-running HTTP server you can point automation at. Put those together and a project that already runs unattended on a cron gets an agent that can run unattended too: nightly checks, CI gates, and issues you triage straight from GitHub.

Two surfaces, one engine

• Sharing is discontinued - govern what leaves - what changed in v1.19.1, how to get a second opinion on the stuck parser session without a share link, and what still leaves your machine - Sharing is discontinued - 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 a CI review, and act on issues through OpenCode’s GitHub integration (as of October 2026) - The server, CI, and GitHub

Hold the two halves together, because they are one architecture, and that’s a practical fact rather than a framing. The interactive session and the headless run are the same engine and project config seen two ways: one you sit in front of, another handed to a machine to execute (opencode run starts a new session unless you pass --continue or --session). If you’re wiring CI this week, that symmetry is what you’re depending on - the permission map, the agents, the AGENTS.md rules, and the plugin gates (plugins that can veto or approve the tool calls their code matches) all load for the run your pipeline triggers at 2am as they do for the session you sit in front of. They don’t bind it equally, and that is the control decision here: AGENTS.md rules are guidance the model usually follows, while the permission map and plugin gates enforce, each only for the tools and paths it matches. Of your own config, only what is committed to the project reaches a CI runner; a permission map in your global ~/.config/opencode/opencode.json stays on your laptop. Another difference is that nobody is there to answer an ask (a permission value that pauses for your approval), which the headless lesson covers. A natural sequence: work the tricky parser session interactively, then turn around and run the same fix as a command. “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 where a human review still matters.

Start with what happened to sharing.