Sharing is discontinued - govern what leaves

You’re deep in a stuck feedmill session - feedmill being the course’s illustrative Go feed aggregator. One source, a German news Atom feed, keeps landing its entries an hour off, and you’re now fairly sure it’s a timezone bug somewhere between the parser and the dedupe key, but you can’t see it. A coworker has fixed exactly this class of bug before, and the instinct is to hand them the whole session as a link.

Until October 2026 OpenCode did exactly that: /share synced the conversation to OpenCode’s servers and minted a public opncd.ai/s/<id> link. That feature has been discontinued. The v1.19.1 release notes (2026-10-15) say: “Session sharing has been discontinued. Existing share links and session-sharing commands are no longer available, and importing sessions from share URLs is unsupported” (release v1.19.1, as of October 2026). The source agrees. In v1.19.4 the share service fails with Session sharing has been discontinued, unshare only clears the local link, and opencode run --share is a hidden deprecated flag that prints the same message (share/session.ts, run.ts). The GitHub integration no longer attaches a session link to its comments either.

The public sharing documentation page has been removed, and the /share entry and share config row are gone from the TUI and config pages (as of October 25, 2026). Whether a pre-1.19.1 client can still publish a link depends on the share service, which this course did not test. Treat sharing as gone.

In OpenCode 2

OpenCode 2 has no sharing either: its --help lists no share command and the v2 docs have no sharing page. Session export moved under session: use opencode session export [session], which also takes --sanitize to redact sensitive transcript and file data, in place of opencode export (checked with opencode session export --help on v2.1.2, October 2026). Review a sanitized export before you send it anyway.

Get a second opinion without a share link

The need did not go away; the transport did. Three substitutes, in order of how much leaves your machine:

• Describe the bug, with evidence. The coworker needs the failing input, the observed and expected output, and the two fixes you tried. For the Atom case that is the feed entry with its offset, the stored time, and the dedupe key it produced. Paste that into chat. It is smaller than a transcript and easier to answer.
• Export the session to a file. opencode export [sessionID] writes the session as JSON, and the TUI has a session_export keybind that opens it in your editor (CLI documentation, keybind.ts, as of October 2026). You choose who receives the file. A JSON export is raw (prompts, tool output, file contents the agent read), so review it before sending it anywhere.
• Reproduce in a clean directory. A minimal repro of the parser bug with the internal feed URLs removed can go to anyone, and the person helping can run it themselves.

What still leaves the machine

Ending the share feature does not make a session local-only. Every turn sends your prompts, the files the agent read, and tool output to whichever model provider answers it. That traffic is governed by your provider choice and your permission map, not by anything sharing-related. For feedmill, the controls that matter are the ones from earlier chapters: a local model for private feeds (local and custom models) and webfetch/websearch gated in the permission map.

The share key (manual, auto, disabled) is still accepted by the v1.19.4 config schema (config.ts), but with sharing removed the setting no longer controls any upload. If you committed "share": "disabled" to a repo’s opencode.json as a guard, it is harmless; it is no longer doing a job, and it is not a substitute for the controls above.

Enforce it above the project

When a rule must hold across every repo, not just this one, there is a higher tier. OpenCode loads a managed/system config layer at the highest priority tier - admin-placed files under /Library/Application Support/opencode/ (macOS), /etc/opencode/ (Linux), or %ProgramData%\opencode (Windows), plus macOS MDM .mobileconfig preferences. The directories “require admin/root access to write, so users cannot modify them,” and managed preference keys “cannot be overridden by user or project configuration” (configuration documentation, as of October 2026). That is where an organization enforces rules that must hold against a user who wants to change them, such as a permission map that denies webfetch, and only on machines the organization manages. A project opencode.json checked into the repo is the lighter tier: it stops accidents and travels with the code, but anyone with a clone can edit it.

In OpenCode 2

v2 expresses admin-enforced restrictions as policies, not as ordinary settings or permissions, because overriding a setting cannot stop users from adding providers, MCP servers, agents or plugins. A policy never prompts and only tightens what permissions would allow. See policies and the migration guide, as of October 2026.

Now take that same stuck session and drive it the other way - not opened up for a human to read, but handed to a machine to run. Next: run OpenCode headless.