Codex review on #3829: when an MCP server lives in a non-writable
source config such as opencode.json with enabled:false, the dashboard
re-enable had nowhere to write to — the writable mcp.json fallback
did not own the server, so setMcpServerEnabled fell through to the
denylist and the source's enabled:false kept the row disabled.
Added a parallel allowlist to the user-level mcp.json that overrides
a non-writable source's enabled:false flag without ever mutating the
foreign config:
- types + schema: new enabledServers array (mirrors disabledServers).
- config-writer: readEnabledServers + setServerForceEnabled helpers,
and setMcpServerEnabled now writes to enabledServers on enable
when no writable mcp.json owns the server, clears it whenever a
writable source becomes the source of truth, and always clears the
override on disable so a force-enabled server can be turned off.
- mcp/config (runtime loader) and state-manager (dashboard read):
honor enabledServers as an override on enabled:false, while still
letting disabledServers win.
- Added a regression test that walks the full lifecycle for an
opencode.json server: enabled:false is surfaced as disabled, the
dashboard re-enable force-enables via enabledServers without
touching opencode.json, then disable clears the override and
populates disabledServers.
Fixes#3827
Codex review on #3829: the dashboard re-enable path still missed MCP
servers loaded from supported non-primary native config files such as
.omp/.mcp.json or user .mcp.json. Those rows carry enabled:false from
their source file, so falling back to the user disabledServers denylist
could not make the row active again.
- setMcpServerEnabled now accepts the loaded row's sourcePath and checks
it before the primary project/user mcp.json paths.
- extension-dashboard passes the source path for writable MCP providers
(native and mcp-json), avoiding accidental edits to third-party tool
configs while still updating .omp/.mcp.json and standalone MCP JSON
sources.
- Added a regression test for a server loaded from .omp/.mcp.json with
enabled:false; re-enable flips that file to enabled:true and does not
write the denylist.
Fixes#3827
Codex review on #3829: when an MCP server's mcp.json entry carries
enabled:false, the dashboard toggle previously only removed the name
from the user-level disabledServers denylist. state-manager's new
`server.enabled === false` check (state-manager.ts:156) then still
marked the row disabled, leaving such servers impossible to re-enable
from /extensions.
Extracted setMcpServerEnabled() into mcp/config-writer.ts mirroring
/mcp enable | /mcp disable semantics:
- Server defined in project mcp.json -> update enabled on that entry.
- Else server defined in user mcp.json -> update enabled on that entry.
- Else (discovered third-party server) -> use the user-level disabledServers denylist.
- On re-enable, always clear any stale denylist entry.
extension-dashboard.ts routes mcp:* toggles through this helper. Added
four new regression tests covering: enabled:false re-enable, mixed
flag+denylist re-enable, disable on a config-resident server writing
enabled:false (not denylist), and discovered-server denylist round-trip.
Fixes#3827
The initial PR update changed the MCP OAuth default prompt to 'login consent'.
The reporter verified Cloudflare's flow actually matches the reference MCP SDK
when no prompt parameter is sent: Cloudflare then reuses the existing account
grant and opens the scope/permission picker first. Forcing any prompt keeps the
flow on Cloudflare's account/consent page instead.
Match the reference SDK behavior: omit prompt by default and send
'prompt=consent' only when the requested scope contains offline_access, where
OIDC Core requires re-consent for offline access. Explicit oauth.prompt values,
including the empty-string omit escape hatch, still take precedence.
Also rename the dynamically registered MCP OAuth client from Codex to oh-my-pi
so Cloudflare consent screens show the current product name.
Fixes#3817
The MCP OAuth flow defaulted the authorization-request prompt parameter
to 'consent'. Per OpenID Connect Core 1.0 §3.1.2.1 that asks the
authorization server to re-prompt for consent only while reusing the
existing browser authentication session. Cloudflare's MCP OAuth server
(and other strict OIDC providers) honor that literally, so /mcp reauth
landed on the consent screen attached to whichever account the browser
cookie was for, leaving no way to switch the signed-in account.
Default to 'login consent' instead so the provider first re-prompts for
authentication (the page Claude Code shows on its reauth flow) and then
re-confirms consent, preserving the original intent of always
re-displaying the authorize screen. RFC 6749 §3.1 requires providers to
ignore prompt values they do not support, so the two-value form is safe
for non-OIDC servers. Existing per-server overrides via mcp.json's
`oauth.prompt` (including the empty-string escape hatch) are unchanged.
Fixes#3817
Kept PATH-resolved Windows npx.cmd shims on the cmd.exe wrapper path so npm owns subprocess stdio exactly like the reporter's working cmd /c configuration.
Fixes#3794
Changed legacy SSE pending requests to reject with a transport-closed error when the persistent stream ends, preserving MCP tool reconnect-and-retry behavior.
Fixes#3710
Rejected legacy SSE endpoint events whose resolved URL uses a different origin than the configured SSE URL, preventing configured headers from being posted cross-origin.
Fixes#3710
Added the MCP protocol 2024-11-05 HTTP+SSE transport so type:"sse" opens the endpoint stream, posts JSON-RPC to the announced endpoint, and correlates streamed responses.
Fixes#3710
OMP injects `INTENT_FIELD` (`i`) into every tool's wire schema. The direct
model tool-call path strips it via `extractIntent` in agent-loop, but the
eval `tool.*` bridge forwards args verbatim, so strict-schema MCP servers
(Linear, anything with `additionalProperties:false` / Zod `.strict()`)
rejected every call with `-32602 unrecognized_keys: ["i"]`. The eval
bridge surfaced the rejection as `hasError: true` instead of throwing, so
batch callers reading the value as success silently mutated nothing.
Move the strip to the MCP boundary so it owns the contract regardless of
caller: `MCPTool.execute` / `DeferredMCPTool.execute` route params through
a new `prepareOutboundArgs` that runs `stripHarnessIntent` before
`omitUnusedOptionalArgs`. `stripHarnessIntent` leaves `i` in place when
the server's own `inputSchema.properties` declares it, so a server that
legitimately uses `i` as a parameter is unaffected.
Fixes#3575
Detected whether the OMP host already owns an inheritable Windows console before resolving stdio MCP spawn flags.
Skipped CREATE_NO_WINDOW for console-attached MCP wrapper chains so cmd.exe and PowerShell grandchildren reuse the existing terminal instead of allocating visible conhost windows.
Fixes#3567
Allowed resource-server fallback OAuth discovery to accept authorization-server metadata whose issuer differs from the resource URL while keeping issuer matching for advertised auth-server candidates.
Added an Atlassian-shaped regression test so the fallback path no longer returns null.
Fixes#3551
StdioTransport.connect() unconditionally passed detached:true to
Bun.spawn. POSIX needs this so terminal job-control signals (SIGTSTP,
SIGTTIN) cannot stop stdio servers such as chrome-devtools-mcp; Windows
has no equivalent signals, but detached:true maps to
CreateProcess(DETACHED_PROCESS), which strips the parent's inherited
console. windowsHide:true (#3536) hides the direct child's window but
nothing else — when the direct child was a hidden cmd.exe wrapper that
later spawned a console grandchild (node wrapper, npx.cmd -y mcp-remote,
similar nested shells) the grandchild allocated a brand-new visible
conhost and its stdout no longer routed through OMP's pipe. The proxy
terminal reported the MCP bridge was healthy while OMP timed out
waiting for the MCP initialize response.
Move detached into StdioSpawnCommand alongside windowsHide so every
platform-derived spawn flag is resolved in one place:
resolveStdioSpawnCommand returns detached:false on every Windows return
shape (direct .exe, cmd.exe-wrapped batch/unresolvable command, npm
cmd-shim launched through node) and detached:true on POSIX. connect()
consumes the resolved flag. Add a regression test for the reporter's
exact shape (cmd.exe /C node wrapper) and assert detached on every
existing Windows / POSIX case so the contract cannot regress per-path.
Fixes#3544
`discoverOAuthEndpoints` probes `/.well-known/oauth-authorization-server` at
the origin root before path-prefixed candidates and returns on the first hit.
Plane hosts a root issuer (`https://mcp.plane.so/`) at origin root and a
separate path-scoped issuer (`https://mcp.plane.so/http`) at the path-prefixed
well-known. The `/http/mcp` endpoint advertises only the path-scoped issuer
through protected-resource metadata, so discovery should follow that issuer's
metadata — instead it accepted the wrong origin-root document and routed the
grant to `https://mcp.plane.so/authorize`, which rejects every request with
`server_error=An unexpected error occurred` before the consent screen.
RFC 8414 §3.3 requires the metadata's `issuer` to equal the URL the client
used to construct the metadata URL. Validate it in the discovery loop: when
the queried well-known is the official authorization-server or OpenID Connect
document, skip metadata whose `issuer` doesn't match (after trailing-slash
normalization). Documents without an `issuer` field keep the existing
permissive behavior so legacy/nonstandard servers continue to work.
Verified live against `https://mcp.plane.so/http/authorize` with the same
client/PKCE: pre-fix `302 -> /callback?error=server_error`, post-fix
`302 -> /http/consent?txn_id=…`. Adds an `oauth-discovery.test.ts`
regression suite covering Plane's wrong-issuer origin-root document plus
trailing-slash and no-issuer paths.
Fixes#3537
Set windowsHide for every Windows stdio MCP spawn path so direct .exe servers no longer open a visible cmd.exe window.
Added a regression test covering direct Windows executable MCP server launch options.
Fixes#3535
Review on PR #3503 caught the last provenance edge case: some servers can
explicitly advertise an origin-only resource equal to the authorization-server
origin. That value is still authoritative provider metadata and must be sent;
only OMP-synthesized fallback resources should be stripped.
- `filterResourceIndicator` now strips same-origin values only when `stripSameOriginResource` is set. Provider-advertised `oauth.resource` and authorization-URL `?resource=` values preserve both origin-only and path-scoped forms.
- Updated grant tests to preserve advertised origin resources, trailing-slash origin resources, and URL-embedded origin resources while still stripping fallback origin/path resources for Plane.
- Updated refresh tests to preserve advertised origin resources and strip only fallback origin/path resources.
- Updated changelog wording to describe fallback-only stripping.
Fixes#3502
Review on PR #3503 caught one remaining provenance hole: a provider can embed a
path-scoped same-host `resource` directly in the authorization URL while
`oauth.resource` remains undefined. The controller marks its separate
`config.url` resource as fallback, but the URL-embedded parameter is still
provider-authored and must not inherit the fallback same-origin stripping
policy.
- `generateAuthUrl` now filters an existing `?resource=` from the authorization URL with the path-preserving default, regardless of `stripSameOriginResource` on the caller-supplied fallback resource.
- Added a regression that simulates `authorize?resource=https://gateway.example.com/svc/mcp` plus fallback `resource=https://gateway.example.com`; the authorize URL, `flow.resource`, and token request all preserve `/svc/mcp`.
- Updated the changelog to explicitly mention authorization-URL-embedded path resources.
Fixes#3502
Review on PR #3503 caught that the broad same-origin filter broke valid
protected-resource discovery shapes such as
`https://gateway.example.com/my-service/mcp`: same host as the authorization
server, but a distinct MCP service identified by path. Those advertised
resources must be preserved for audience selection.
- Replaced the unconditional same-origin filter with a provenance-aware policy: exact auth-server-origin resources are always stripped, path-scoped same-origin resources are preserved by default, and only OMP-synthesized fallback resources opt into same-origin path stripping.
- Added `stripSameOriginResource` to `MCPOAuthConfig` and `RefreshMCPOAuthTokenOptions`; quick-add/reauth set it only when the resource came from `config.url` / `runtimeBaseConfig.url` fallback rather than `oauth.resource` or an existing auth resource.
- Refresh uses the same flag when `MCPManager.prepareConfig` falls back to `config.url`, and no longer persists fallback resources into the credential as if they were provider-advertised material.
- Updated RFC 8707 tests to cover both sides: gateway path resource preserved, Plane-style fallback `/http/mcp` stripped, refresh path mirrors the same distinction.
Fixes#3502
Plane also rejects `resource=https://mcp.plane.so/http/mcp`, not only the bare
origin forms. That means the MCP OAuth resource filter must treat any resource
URL on the authorization-server origin as redundant for these MCP servers, not
just exact origin/origin-slash values.
- Broadened the filter to compare `new URL(resource).origin` with the persisted authorization-server origin.
- Updated grant and refresh RFC 8707 tests: same-origin path resources such as `/http/mcp` are now stripped from authorize, token exchange, and refresh; cross-origin resources remain preserved.
- Updated docs/changelog wording from exact self-referential origin to same-origin resource indicators.
Verified live against `https://mcp.plane.so/authorize`: patched `MCPOAuthFlow` with `resource=https://mcp.plane.so/http/mcp` generates no `resource` parameter and Plane redirects to `/consent?txn_id=…`.
Fixes#3502
Review on PR #3503 flagged that the prior fix anchored the initial-grant filter
on `authorizationUrl` but the refresh filter on `tokenUrl`. RFC 8414 lets the
authorize and token endpoints sit on different origins, so when they do, a
`config.url` fallback equal to the auth-server origin survives the refresh
filter — the credential works until expiry, then refresh resurrects the same
self-referential `resource` the authorize/token exchange intentionally
omitted.
- `MCPStoredOAuthCredential.authorizationUrl?: string` — new field, the issuer the grant was minted against.
- `MCPOAuthFlow.authorizationUrl` getter exposes the value so the persistence site can write it (symmetric with `flow.resource`).
- `refreshMCPOAuthToken` accepts `{ authorizationUrl }` via the trailing options object; filters self-referential indicators against the supplied URL, falling back to `tokenUrl`'s origin for legacy credentials. New `RefreshMCPOAuthTokenOptions` interface keeps the positional resource form working.
- `mcp-command-controller.ts` persists `flow.authorizationUrl` on credential write; `manager.ts` extracts it from the embedded credential material (legacy `MCPAuthConfig` rows lack it and continue through the `tokenUrl` fallback) and threads it to `refreshMCPOAuthToken`.
- Tests: 3 new cross-origin refresh cases — stripped when resource equals auth-server origin with cross-origin token endpoint; preserved when resource points at a third origin; legacy `tokenUrl`-anchored fallback still works without `authorizationUrl`. Plus a `flow.authorizationUrl` getter test. Updated `mcp-manager-oauth-refresh.test.ts` to account for the new opts arg.
Fixes#3502
When the initial grant strips a self-referential resource (per the previous
commit), the credential is stored with `resource: undefined`. On the next
refresh, `MCPManager.prepareConfig` (`packages/coding-agent/src/mcp/manager.ts:1232-1233`)
falls back from `material?.resource` to `config.url` and pipes it into
`refreshMCPOAuthToken` — re-introducing the same self-referential value that
broke the initial authorize against strict servers like Plane. RFC 8707 §2.2
also requires the token-request indicator to match the authorize indicator,
so dropping in one mandates dropping in the other.
- Hoisted `filterSelfReferentialResource(resource, serverUrl)` to module scope so the class-method form and the free `refreshMCPOAuthToken` share the rule. `MCPOAuthFlow.#filterResourceIndicator` is now a thin delegate.
- `refreshMCPOAuthToken` now passes the resource through the same filter, using `tokenUrl` as the origin yardstick (RFC 8414 puts authorize and token endpoints on the same issuer, and MCP discovery follows that contract).
- Added 3-test `RFC 8707 resource indicator (refresh)` suite covering: resource equals token-server origin (stripped), origin with trailing slash (stripped), and a path-bearing resource (preserved).
Fixes#3502
Some MCP authorization servers reject `resource=<auth-server-origin>` with
`server_error&error_description=An+unexpected+error+occurred` before the
consent screen is shown. Plane (`https://mcp.plane.so`) is the live example:
`resource=https://mcp.plane.so` or `https://mcp.plane.so/` errors; the same
authorize request with no resource (or a path-bearing resource like
`https://mcp.plane.so/sse`) succeeds.
Per RFC 8707 §2 the resource indicator distinguishes *other* resource servers
from the authorization server, so a self-referential value is never required.
`MCPOAuthFlow` now strips a resource that equals the authorization-server
origin (with or without trailing slash) in three places:
- the constructor, when resolving the configured resource;
- `generateAuthUrl()`, including the URL-override path that re-reads `?resource=` from the authorize URL;
- `exchangeToken()`, which reads `this.#resource` (RFC 8707 §2.2 requires the token request indicator to match the authorize request, so dropping in one mandates the other).
Verified live against `https://mcp.plane.so/authorize`: pre-fix the generated
URL produces `302 → /callback?error=server_error&…`; post-fix it produces
`302 → /consent?txn_id=…`.
Fixes#3502
Pruned empty optional MCP argument placeholders before tools/call while preserving required fields and meaningful falsy values.
Added regression coverage for active and deferred MCP tools.
Fixes#3302
Bun.spawn -> CreateProcess only appends `.exe` to extensionless names; `.cmd`/`.bat` are never tried. Bare MCP commands like `npx` (which exists only as `npx.cmd` on Windows) crashed the subprocess ~140ms after spawn with ENOENT/EINVAL whenever our own PATH walk couldn't pin the file down (empty `Bun.env.PATH` under a restricted parent process, UNC mounts that reject `fs.access`, locked-down shells).
`resolveStdioSpawnCommand` now routes any unresolved bare command through `cmd.exe /d /s /c` so Windows's PATHEXT search runs Windows-native. Direct-spawn fast path is preserved for resolved `.exe`/`.com` files; the existing `.cmd`/`.bat` wrap is unchanged. The reporter's stated cause ("process.env not merged") was incorrect — the merge has been in place at `transports/stdio.ts:316-319` since well before 16.1.14 — but the symptom they hit is real.
Fixes#3250
Sanitized MCP server names before status formatting so configured keys cannot leak home paths, tabs, newlines, or oversized text into the TUI.
Fixes#3150
Emitted MCP connection lifecycle events through the startup event bus so the TUI can replace the initial connecting banner with connected, pending, or failed server state.
Added manager and interactive-mode coverage for mixed success/failure MCP startup updates.
Fixes#3150
- Wrapped MCP call and result renderers in WidthAwareText so formatting can use runtime content width.
- Computed inline argument preview budget from the available content width instead of a fixed 70-character cap.
- Updated raw text truncation in MCP results to target the measured content width while preserving expand hints and warnings.
- Sanitized artifact filenames by normalizing tool names before composing spill paths.
- Applied `wrapToolWithMetaNotice` to custom tool adapters and RPC-host tools in agent-session setup.
- Wrapped SDK-registered extension/custom tools with the same meta-notice adapter during session creation.
- Fixed OAuth credentials to keep unknown fields in schema while preserving existing shape checks.
- Fixed MCP OAuth IDs to be profile-scoped and avoid deleting credentials from non-active profiles.
- Fixed string-flag parsing so PROFILE_BOOTSTRAP_BOUNDARY tokens are not consumed as values.
- Fixed active-profile directory resolution to refresh after env updates so profile .env overrides apply.
Deferred MCP discovery wrote 'Connecting to MCP servers: …' straight to process.stderr while the TUI owned the terminal, overdrawing the chat input box border. onMCPConnecting now emits McpConnectingEvent on the mcp:connecting channel; InteractiveMode subscribes and renders it via showStatus (status container), mirroring the LSP-startup pattern. New mcp/startup-events.ts holds the channel, type, and formatMCPConnectingMessage.
roboomp