Name stdio MCP OAuth clients and isolate auth caches

[Sayan-]

Summary

• Set the OAuth client name for each stdio MCP target, including Goose's printed YAML.
• Give each target a separate mcp-remote auth cache and callback port so clients can authorize independently and do not share a client identity. Preserve existing explicit callback ports.
• Preserve existing environment settings, mcp-remote options, and other OAuth metadata fields. Reject external metadata files with a clear error instead of changing them.
• Include Goose's required enabled field in the printed config.

Validation

• Extended install tests for client names, cache isolation, distinct callback ports, preserved explicit ports, existing metadata and environment settings, malformed settings, duplicate OAuth metadata, and repeated installs.
• Built the CLI and parsed the printed Goose config as YAML, including its enabled flag, string callback-port argument, metadata, and cache path.
• Verified all five generated stdio configs can hold independent callback listeners simultaneously using mcp-remote 0.14.3. Verified earlier configs without a port upgrade correctly.
• Live desktop OAuth flows were not exercised.

Rollout

Existing stdio installs will prompt for authorization again when the new per-client cache is used. A custom nonempty MCP_REMOTE_CONFIG_DIR remains in place and may require manual cache cleanup. Existing explicit callback ports remain in place; custom ports must be distinct across clients. Existing shared cache files are left untouched because other MCP clients may use them.

---

Note

Medium Risk
Changes how stdio MCP OAuth is configured and where tokens are stored, which can force re-authorization and affect users with custom ports or metadata; install remains conservative on invalid or external metadata.

Overview
Stdio MCP installs now generate per-target mcp-remote invocations with a dedicated OAuth client name, callback port (46093–46097), and MCP_REMOTE_CONFIG_DIR under ~/.mcp-auth/kernel-<target> so multiple editors can authorize independently without sharing identity or cache.

Install merge logic was reworked: default args come from stdioArgs(spec) instead of per-target stdioArgs slices; existing args keep custom flags/versions while upgrading URL, inserting a port when missing, and merging --static-oauth-client-metadata (other JSON fields preserved; external @ metadata files fail with a clear error). Non-empty custom cache paths are left alone; empty cache values are replaced.

Goose printed YAML now includes enabled: true, the same stdio args/env as JSON targets, via a new gooseConfig helper; gopkg.in/yaml.v3 is a direct dependency for parsing that output in tests.

^{Reviewed by Cursor Bugbot for commit 9039534. Bugbot is set up for automated code reviews on this repo. Configure here.}

[masnwilliams]

The stdio OAuth command now has two independent construction paths: stdioArgs builds the URL, callback port, and metadata for JSON targets, while gooseConfig repeats them in YAML. That makes the generated Goose instructions easy to drift from the installed clients on the next argument change, and the substring test only verifies today’s literals. Please render Goose’s args from stdioArgs(spec) and assert that the parsed YAML args equal that shared sequence. This keeps the transport command in one canonical place without changing behavior.

[masnwilliams]

The latest update resolves my requested change: Goose now renders its arguments from the shared stdio defaults, and the YAML test checks parity. I reran the full Go test suite and MCP vet; both pass.