vault set rejects clientInfo from OAuth dynamic client registration

[feniix]

What happens

mcporter vault set <server> --stdin rejects client info that came from OAuth dynamic client registration. It prints:

[mcporter] Vault payload clientInfo.redirect_uris must be a string.

redirect_uris is an array, not a string. RFC 7591 registration responses always return it as an array. So any real DCR result is rejected and nothing is saved.

This worked in 0.12.0. It broke in 0.12.1 and is still broken in 0.13.0.

Steps to reproduce

1. Create ~/.mcporter/mcporter.json:

   {"mcpServers":{"demo":{"url":"https://example.test/mcp","auth":"oauth"}}}

2. Pipe a payload to vault set:

   echo '{"tokens":{"access_token":"fake","token_type":"Bearer"},"clientInfo":{"client_id":"abc","redirect_uris":["https://example.test/cb"],"grant_types":["authorization_code"],"response_types":["code"],"token_endpoint_auth_method":"none"}}' \
     | mcporter vault set demo --stdin

The access token is fake, so no real credential is involved. The server URL is never contacted.

What you get

On 0.12.1 and later, it exits with code 1 and prints:

[mcporter] Vault payload clientInfo.redirect_uris must be a string.

On 0.12.0, the same command succeeds:

Saved OAuth credentials for 'demo' to <data-dir>/mcporter/credentials.json

If you run the 0.12.0 case, remove the test entry afterwards with mcporter vault clear demo.

What I expected

The payload is saved. redirect_uris is a normal part of client info.

Where it comes from

In dist/cli/vault-command.js:

function validateOAuthClientInfo(clientInfo) {
    for (const [key, value] of Object.entries(clientInfo)) {
        if (value !== undefined && value !== null && typeof value !== 'string') {
            throw new CliUsageError(`Vault payload clientInfo.${key} must be a string.`);
        }
    }
}

This requires every value to be a string. But dist/oauth-client-info.d.ts types client info as OAuthClientInformationMixed from the MCP SDK, and in @modelcontextprotocol/sdk/shared/auth that is:

type OAuthClientInformationMixed = OAuthClientInformation | OAuthClientInformationFull;

Neither member of that union can pass the check:

• OAuthClientInformation has client_id_issued_at and client_secret_expires_at, both numbers.
• OAuthClientInformationFull adds redirect_uris, grant_types and response_types, all arrays of strings.

So the only client info the command accepts is client_id plus optional string fields. Any registration response that carries issuance timestamps or metadata is refused, even though the declared type allows it.

--tokens-file has the same problem. Both sources go through validateVaultPayload, so there is no way around it.

Versions

Version	Result
0.12.0	works
0.12.1	fails
0.12.2	fails
0.12.3	fails
0.12.4	fails
0.13.0	fails

Node 24, macOS. Nothing here looks platform specific.

Suggested fix

Check each field for its own type instead of requiring strings everywhere:

• redirect_uris, grant_types, response_types — array of strings
• client_id_issued_at, client_secret_expires_at — number
• client_id, client_secret, client_name, token_endpoint_auth_method — string

Dropping the clientInfo check and keeping the tokens checks would also fix it.

Related

#244 is also about clientInfo on vault entries, but the other way around: it goes missing after authorization. These may be worth looking at together.

Workaround

For anyone blocked on this: the write goes through if you trim clientInfo to the string-only subset the validator accepts before piping it to vault set.

With jq:

jq -c '.clientInfo |= with_entries(select(.value | type == "string"))' payload.json \
  | mcporter vault set demo --stdin

Applied to the payload from the report, that leaves {"client_id":"abc","token_endpoint_auth_method":"none"} and the command succeeds on 0.12.1+.

The same trim in TypeScript, if you are shelling out to vault set from code:

/** The string-only subset of client info that `mcporter vault set` accepts. */
interface VaultClientInfo {
  client_id: string;
  token_endpoint_auth_method: string;
  client_secret?: string;
  client_name?: string;
}

function toVaultClientInfo(info: OAuthClientInformationFull): VaultClientInfo {
  return {
    client_id: info.client_id,
    token_endpoint_auth_method: info.token_endpoint_auth_method,
    ...(info.client_secret !== undefined ? { client_secret: info.client_secret } : {}),
    ...(info.client_name !== undefined ? { client_name: info.client_name } : {}),
  };
}

What it costs

Dropping redirect_uris, grant_types, response_types, client_id_issued_at and client_secret_expires_at is only safe when the caller owns registration:

• Refreshes keep working. A refresh_token grant sends no redirect URI, and the MCP SDK reads client_id and token_endpoint_auth_method when it authenticates the refresh call — so those two are the ones worth keeping.
• If you depend on mcporter re-registering the client, the trimmed entry no longer carries the metadata for it. We do registration ourselves and hand mcporter the result, so mcporter never re-registers.

This is a workaround, not a fix. The validator still contradicts the OAuthClientInformationMixed type the command declares it accepts, and a schema-aware validator would let the full registration response through.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 8, 2026, 4:44 PM ET / 20:44 UTC.

Summary
Keep open: current main still rejects standard array-valued OAuth client metadata, and two clean, proof-backed pull requests explicitly implement the repair. Select one candidate and let GitHub close this issue when it merges.

Reproducibility: yes. Current main’s string-only loop deterministically rejects the report’s redirect_uris array before any server contact, and the repository itself constructs the same array-valued client shape.

Root-cause cluster
Relationship: canonical
Canonical: #286
Summary: This issue is the canonical report for the vault-import validation defect; two open pull requests are competing candidate fixes.

Members:

• fixed_by_candidate: fix(vault): accept dynamic client registration clientInfo in vault set #287 - It explicitly links to this issue and changes the reported vault client-information validator.
• fixed_by_candidate: fix: accept OAuth DCR metadata in vault set #288 - It explicitly links to this issue and changes the reported vault client-information validator.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Maintainer decision needed

Question	Recommendation
Which of the two overlapping, proof-backed pull requests should become the single fix for this OAuth vault-import regression?	Adopt the narrower reported-case fix: Review and merge #288 if its focused validation and command-level regression coverage match the intended import contract.

Why: Both candidates address the same confirmed defect but differ in scope, so choosing the accepted compatibility boundary requires maintainer ownership rather than another duplicate repair branch.

Next step
Two active linked PRs already own the concrete repair; maintainers need only select one rather than dispatching duplicate work.

Review details

Best possible solution:

Land one focused validator change that accepts standard DCR arrays and timestamps while retaining regression coverage for malformed payloads, then close the issue through the merged pull request.

Do we have a high-confidence way to reproduce the issue?

Yes. Current main’s string-only loop deterministically rejects the report’s redirect_uris array before any server contact, and the repository itself constructs the same array-valued client shape.

Is this the best way to solve the issue?

Yes. Per-field validation with focused persistence regression coverage is the narrow maintainable repair; choose one existing linked PR rather than opening another implementation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The two overlapping candidate fixes differ in scope; merging both would duplicate competing validation behavior, so maintainers should choose one focused implementation.

Codex review notes: model internal, reasoning high; reviewed against ba80d985c867.

Label changes

Label changes:

• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.

Label justifications:

• P1: A current regression prevents legitimate OAuth credential imports needed by headless provider workflows.
• impact:auth-provider: The rejected fields are OAuth dynamic-client-registration metadata consumed by credential persistence and refresh.

Evidence reviewed

What I checked:

• Current-main defect: The client-information validator rejects every non-null value that is not a string, so redirect_uris arrays fail before credentials are saved. (src/cli/vault-command.ts:154, ba80d985c867)
• MCPorter produces and consumes array-valued metadata: Static OAuth client information creates redirect_uris, grant_types, and response_types as arrays, and the OAuth flow reads redirect_uris as an array. (src/oauth-client-info.ts:15, ba80d985c867)
• Supported workflow: The documentation explicitly supports headless vault set imports with a clientInfo payload. (docs/config.md:259, ba80d985c867)
• Release and main check: The v0.13.0 tag contains the current validation implementation, and current main is newer while retaining the same string-only loop; the reported behavior is not fixed in the latest release or on main. (src/cli/vault-command.ts:154, 49dcd3e7fffd)
• Active candidate fixes: Two open, clean pull requests explicitly link to this issue and include real CLI behavior proof: fix(vault): accept dynamic client registration clientInfo in vault set #287 and fix: accept OAuth DCR metadata in vault set #288. (912fe614e0bc)
• Area history: History identifies headless vault seeding and repeated OAuth/vault maintenance as the central feature lineage. (src/cli/vault-command.ts:47, a64e29b4fea3)

Likely related people:

• steipete: History attributes the headless OAuth vault-seeding feature and most follow-on OAuth/vault work to Peter Steinberger; current blame also maps the validator to that lineage. (role: headless-vault feature owner and recent OAuth-area contributor; confidence: high; commits: a64e29b4fea3, 49dcd3e7fffd, 69c98e88127c; files: src/cli/vault-command.ts, src/oauth-vault.ts, src/oauth-client-info.ts)
• feniix: The reporter supplied the isolated reproduction and owns one of the two linked, proof-backed repair branches. (role: active repair author and reporter; confidence: high; commits: 912fe614e0bc; files: src/cli/vault-command.ts, tests/vault-validation.test.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.