You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
config: share and enterprise are accepted, normalised, and read by nothing #57932
share and enterprise are both accepted by the v2 config schema, normalised, and then read by nothing. A user who sets either gets no behaviour and no warning.
share is the clearer one, because it still has a migration path:
so a v1 autoshare: true is still migrated into share: "auto" — into a field nothing reads. The session sharing backend was retired in #55716 ("chore: retire session sharing backend"), and the config key was left behind.
The full set of references in the repository:
packages/schema/src/config.ts:42 — the schema field itself ("manual" | "auto" | "disabled")
packages/core/src/config/normalize.ts:79-99 — the legacy autoshare migration
packages/core/src/config/normalize.ts:210 — the field being passed through the normaliser
packages/schema/src/config.ts:45 / normalize.ts:211 — the same three for enterprise ({ url })
Nothing else. A grep across packages/ for config.share, config.enterprise and enterprise?.url returns nothing.
Neither key appears in the config reference, which is fortunate rather than by design — documenting them would be documenting a ghost.
Two ways this could go, and I am not sure which is intended:
Remove them from the schema (and drop the autoshare migration), so the config surface matches what the CLI does.
Wire them up — share reads naturally as "allow/deny session sharing", and enterprise.url as the sharing service endpoint.
Whichever it is, the current state is the worst of both: a user can set these, the config validates, and nothing happens.
Steps to reproduce
Add "share": "auto" to opencode.json.
Start opencode — no warning, no error, and the setting has no effect.
Same for "enterprise": { "url": "https://example.com" }.
changed the title [-]config: and are accepted, normalised, and read by nothing[/-][+]config: share and enterprise are accepted, normalised, and read by nothing[/+]on Oct 21, 2026
Thanks for the detailed report. I can confirm this on @opencode/cli 2.1.2 and on the latest dev (e441dafb).
On 2.1.2, putting "share": "auto", "autoshare": true and "enterprise": { "url": "https://example.com" } in opencode.json and running opencode debug config resolves to { share: "auto", enterprise: { url: … } } with no warning.
On dev, ConfigNormalize.normalize returns the same result with empty diagnostics, and autoshare: true is still migrated to share: "auto".
Related: #55716 (retired the sharing backend and marked the session.share keybinds as deprecated rather than removing them) and #55718 (the v1 equivalent). Whether to deprecate these keys with a warning or remove them is up to the maintainers. The script below reproduces it.
Reproduction script (repro.sh)
#!/usr/bin/env bash# Repro for #57932: `share`, `autoshare` and `enterprise` validate silently but nothing reads them.# Usage: ./repro.sh (uses `opencode` on PATH)# OC_DEV=/path/to/checkout ./repro.sh (runs from source)set -u
P=$(mktemp -d);cd"$P"; git init -q
cat > opencode.json <<'J'{ "$schema": "https://opencode.ai/config.json", "share": "auto", "autoshare": true, "enterprise": { "url": "https://example.com" }}Jif [ -n"${OC_DEV:-}" ];thenoc() { bun --conditions=browser --preload="$OC_DEV/packages/tui/node_modules/@opentui/solid/scripts/preload.js""$OC_DEV/packages/cli/src/index.ts""$@"; }
elseoc() { opencode "$@"; }; fiecho"== version"; oc --version
echo"== debug config (look for diagnostics/warnings)"; oc debug config 2>&1echo"== control: an unknown key, for comparison"
mkdir -p ctl &&echo'{ "notARealKey": 1 }'> ctl/opencode.json && (cd ctl && git init -q && oc debug config 2>&1| tail -15)
echo"== /share command in v2?"; oc run --help 2>&1| grep -i share ||echo"(no share flag)"if [ -n"${OC_DEV:-}" ];thenecho"== ConfigNormalize.normalize on the checkout (diagnostics should be empty if the bug is present)"
cat >"$OC_DEV/packages/core/.repro-57932.ts"<<'TS'import { normalize } from "./src/config/normalize.ts"console.log(JSON.stringify(normalize({ share: "auto", enterprise: { url: "https://example.com" } })))console.log(JSON.stringify(normalize({ autoshare: true })))TS
(cd "$OC_DEV/packages/core"&& bun run ./.repro-57932.ts); rm -f "$OC_DEV/packages/core/.repro-57932.ts"echo"== runtime readers of share/enterprise in $OC_DEV/packages (excluding config schema/normalize/tests, console, stats):"
grep -rnE "\.share\b|\.enterprise\b|enterprise\??\.url""$OC_DEV/packages" --include=*.ts --include=*.tsx \
| grep -v node_modules | grep -vE "packages/(console|stats|function)/|/test/|config/normalize.ts|schema/src/config.ts"||echo"(none)"fi
Activity
[-]config: and are accepted, normalised, and read by nothing[/-][+]config: share and enterprise are accepted, normalised, and read by nothing[/+]opencode-agent commentedon Oct 21, 2026
Thanks for the detailed report. I can confirm this on
@opencode/cli2.1.2 and on the latestdev(e441dafb)."share": "auto","autoshare": trueand"enterprise": { "url": "https://example.com" }inopencode.jsonand runningopencode debug configresolves to{ share: "auto", enterprise: { url: … } }with no warning.dev,ConfigNormalize.normalizereturns the same result with empty diagnostics, andautoshare: trueis still migrated toshare: "auto".shareas controlling it.Related: #55716 (retired the sharing backend and marked the
session.sharekeybinds as deprecated rather than removing them) and #55718 (the v1 equivalent). Whether to deprecate these keys with a warning or remove them is up to the maintainers. The script below reproduces it.Reproduction script (repro.sh)
Run it:
bash repro.sh