OpenCode Session Sharing: Privacy Checks, Disable, and Unshare

Before you send an OpenCode session to a teammate, treat the link as a small public release—not as a private invitation addressed to one person. OpenCode’s documentation says a shared conversation is publicly accessible to anyone with the link. For most teams, the safe pattern is manual sharing after a full review, or disabled sharing for sensitive projects, followed by /unshare as soon as collaboration ends.

What an OpenCode share link exposes

A share link contains the session, not only the last answer you want a teammate to see. According to the official OpenCode Share documentation, sharing creates a unique public URL, syncs the conversation history to OpenCode’s servers, and makes it available through that link. The published material includes:

• the full conversation history;
• every message and response;
• session metadata.

This does not mean OpenCode automatically publishes every file on your local disk. The practical risk is that source code, configuration, logs, command output, or file contents become part of the shared history whenever they appear in a message or response. The standard link is also not restricted to the teammate you send it to: anyone who obtains the URL can open it.

A shared session remains accessible until you explicitly unshare it. Do not review only the final exchange, and do not treat an unguessable-looking URL as access control.

Choose manual or disabled sharing—not auto by accident

For ordinary work, decide between manual and disabled. Use auto only when you deliberately want every new conversation to be shared before a person reviews it.

Mode	What it does	Good fit	Main risk
manual	Default mode; a link is created only after /share	Occasional, reviewed collaboration	A reviewer can miss something, but new sessions are not shared automatically
auto	Every new conversation is shared and gets a link	Deliberately public workflows	Secrets, code, or logs can be published before review
disabled	Turns sharing off	Private repositories, customer data, regulated work, or teams that do not need public links	The standard share link is unavailable, so use another controlled collaboration method

The decision rule is simple: use manual when you occasionally need to show a reviewed session; use disabled when the project is sensitive, public links are unnecessary, or the team cannot reliably perform a pre-share review. Do not enable auto merely to save the step of entering /share.

Review the entire session before sharing

Read from the first message to the last. Because the public page includes the full history, cleaning the snippet you plan to paste into a team chat is not enough. If sensitive material remains anywhere in the original session, do not share that session.

1. Credentials and authentication material

Search for API keys, access tokens, passwords, private keys, cookies, session tokens, Authorization headers, database connection strings, signed URLs, and real values copied from .env files. Variable names and placeholders may be harmless; live values are not.

If a credential is already in the session and you cannot confirm that it has been removed from the history, the safer response is to revoke or rotate it, create a clean session without the secret, and share the clean session instead.

2. Proprietary code and business context

Check source files, patches, configuration, SQL, architecture notes, customer names, internal requirements, and unreleased features that the model read or produced. A single fragment may look harmless, but several fragments can reveal system structure, business logic, or security boundaries.

3. Logs and command output

Logs and errors often expose local paths, usernames, email addresses, hostnames, internal domains, IP addresses, repository names, branch names, ticket IDs, database names, or request parameters. Search beyond words such as token and password: inspect stack traces, test output, CI logs, git diff, curl commands, and terminal output.

4. Session metadata and identifying context

OpenCode explicitly lists session metadata as shared data. Even after you clean the prose, review project names, session titles, branches, file paths, and other details that could identify an organization or system.

5. If reliable cleanup is impossible, start a clean session

The public documentation does not promise automatic redaction. Do not assume OpenCode will mask credentials, and do not share first in order to “see what happens.” Recreate the minimum code, error, and context needed for collaboration in a clean session; that is usually more reliable than trying to prove a long session contains no sensitive residue.

How to share safely in manual mode

manual is the default and the best fit for a review-before-publish workflow.

Step 1: Confirm the effective share setting

OpenCode merges configuration from several locations, and later sources override earlier ones when the same key conflicts. The global config is normally ~/.config/opencode/opencode.json; the project config is opencode.json in the repository root. Run:

opencode debug config

Check the resolved output and make sure share is actually manual, not auto from another source. See the official OpenCode Config documentation for locations and precedence.

To set manual mode explicitly, add this to the appropriate opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "share": "manual"
}

Step 2: Complete the privacy review

Apply the checklist above to the complete history. If any credential, proprietary code, confidential log, or identifying metadata cannot be published, stop. Create a clean, minimal session if collaboration still needs to continue.

Step 3: Run /share in the session you reviewed

/share

The official documentation says this creates a unique URL and copies it to your clipboard. Do not forward it immediately; first review it as the public page it is.

Step 4: Inspect the link from the recipient’s perspective

Open the URL in a signed-out browser or private window and read the public page from top to bottom. Confirm that it contains only material you are willing to expose to anyone who obtains the link, including content hidden in long logs or early messages.

This is a publication check, not another permission layer. Viewing it in a private window does not make the standard link private.

Step 5: Send it through a controlled channel and set an expiry point

Send the URL only in the team channel that needs it, and ask recipients not to forward it. That request reduces accidental spread but cannot technically bind the link to those recipients. Decide at the time of sharing when you will revoke it—for example, when the bug is resolved, the review closes, or a stated time window ends.

How to disable sharing for a sensitive project

If a project contains customer data, production credentials, proprietary code, or no legitimate need for public session links, disabled is safer than relying on every contributor to remember every review step.

Add this to opencode.json in the project root and commit it to Git:

{
  "$schema": "https://opencode.ai/config.json",
  "share": "disabled"
}

The official Share documentation recommends a project config for applying this choice across a team. Because OpenCode merges configuration, still run opencode debug config to verify the final value, especially when inline or administrator-managed settings may override project configuration.

For an organization-wide rule that normal users cannot change, administrators should use managed settings. The current Config documentation lists /Library/Application Support/opencode/ on macOS, /etc/opencode/ on Linux, and %ProgramData%\opencode on Windows; managed settings have higher precedence than user and project files. Enterprise deployments can also restrict sharing to SSO-authenticated users or self-host it.

How to revoke an existing share link

Revocation is an explicit cleanup step. Closing the terminal, deleting the message that carried the URL, or clearing your clipboard does not unshare an already public session.

Step 1: Return to the original session and run /unshare

/unshare

OpenCode’s documentation says this removes public access, removes the share link, and deletes data related to that shared conversation.

Step 2: Verify the old URL no longer shows the session

Keep the original URL and open it again in a signed-out window or another browser. The meaningful success signal is that the old link no longer displays the shared conversation—not merely that the command returned without an obvious error. If it still opens, confirm that you unshared the correct session and inspect the effective configuration and client state.

Step 3: Treat a failed verification as an active public link

The current public Share page documents /unshare from the original conversation; it does not list a separate public dashboard for managing links. If you cannot reopen the session, the command is unavailable, or the old URL still exposes content, do not tell the team it has been revoked. Treat the URL as public and contact your OpenCode administrator or OpenCode support until external access is confirmed to be gone.

What /unshare can and cannot undo

/unshare stops OpenCode from continuing to serve the shared conversation at the old link. It cannot make a recipient forget what they saw, or retrieve screenshots, copied code, downloaded logs, and other copies they saved earlier.

The official page says the share-related conversation data is deleted, but it does not promise to erase third-party caches, browser copies, or recipient-created archives. Revocation is therefore necessary cleanup, not a substitute for review before sharing. If a live credential was exposed, rotate or revoke the credential as well as running /unshare.

Common questions

Does the link expose my entire local repository?

The documentation names full conversation history, messages and responses, and session metadata; it does not say that every local file is automatically published. However, any code, file content, patch, or log that entered the conversation is part of the material you must review.

Can I allow only one teammate to open the link?

The standard Share documentation describes a public link that anyone with the URL can access, not a per-email allowlist. Organizations needing identity restrictions should evaluate the documented enterprise options, such as SSO-only access or self-hosting.

Why did a new session get a link when I never ran /share?

Check whether the resolved setting is auto. Run opencode debug config, then inspect global, project, environment-provided inline, and managed configuration to identify the source that wins.

What if /share is unavailable?

Check whether the final share value is disabled or locked by managed settings. Do not bypass a team policy with a lower-precedence file; ask the administrator which approved collaboration method to use.

Final checklist before sending the URL

Before you press Send, confirm all of the following:

• the effective mode is manual, or the project is intentionally set to disabled;
• you reviewed the history from the first message onward;
• no live credentials, internal URLs, proprietary code, customer data, or sensitive logs remain;
• you opened the public page in a signed-out window;
• you know who needs the link, which channel will carry it, and when it will be revoked;
• after collaboration, you will run /unshare in the original session and verify the old URL no longer displays the content.

Once you treat session sharing as publication rather than as an ordinary chat attachment, the important privacy decisions become much easier to see before the link leaves your hands.