Summary

Fixes #286. mcporter vault set rejects every clientInfo value that is not a string, so no real dynamic client registration response can be seeded into the vault. In RFC 7591, redirect_uris, grant_types, response_types and contacts are string arrays, and client_id_issued_at and client_secret_expires_at are numbers. A headless deployment that already holds OAuth credentials has no way to install them.

The declared type says otherwise. VaultPayload.clientInfo is OAuthClientInformationMixed, and mcporter builds that same array-valued shape itself in buildStaticClientInformation (src/oauth-client-info.ts:15) and during registration (src/oauth.ts:115), then reads clientInfo.redirect_uris back as an array (src/oauth.ts:506). Its own client information cannot round-trip through its own command.

Root cause

src/cli/vault-command.ts:154

function validateOAuthClientInfo(clientInfo: Record<string, unknown>): void {
  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.`);
    }
  }
}

One rule for every field. validateOAuthTokens, directly above it, already does the opposite: access_token and token_type non-empty strings, refresh_token/scope/issuer optional strings, expires_in a finite number. So the tokens half of the payload accepts its real shape and the client-information half does not.

Fix

validateOAuthClientInfo now checks each field against the JSON type OAuthClientInformationFullSchema declares for it (@modelcontextprotocol/sdk/shared/auth.js), in that schema's declaration order:

The loop walks the rule table rather than the payload. Unknown keys therefore pass through untouched, so a full registration response keeps registration_client_uri, registration_access_token and whatever else the provider returned, and the reported field no longer depends on JSON key order. jwks stays unconstrained because the SDK types it as z.any(). redirect_uris stays optional even though the schema's wide member requires it, since the narrow member OAuthClientInformation is equally valid here. null is still treated as absent, as before.

URL-shaped fields are only checked for being strings. The SDK's SafeUrlSchema would additionally require a parseable URL. That starts rejecting redirect URIs that are legal in the wild, such as urn:ietf:wg:oauth:2.0:oob and custom-scheme mobile redirects, which is the wrong trade in a change whose point is to stop over-rejecting.

I kept the SDK's zod schemas out of this path for a related reason. They are all .strip(), so validating through them invites persisting result.data, which would quietly drop seeded fields the vault depends on: tokens.expires_at is read at src/oauth-persistence-stores.ts:37, src/oauth-token-refresh.ts:33 and src/runtime/oauth.ts:123, and validateVaultPayload deliberately returns the raw objects by reference. A union of OAuthClientInformationFullSchema and OAuthClientInformationSchema would not validate much either, since the second member requires only client_id and strips the rest, so { client_id: "abc", redirect_uris: 42 } passes it.

validateVaultPayload is unchanged, including the order in which it validates tokens before client information.

Also: three fields the read path requires and the write path did not check

externalVaultEntry (src/oauth-vault.ts:220) runs stored credentials through isStoredOAuthTokens and isStoredOAuthClientInformation, and drops the whole tokens or clientInfo object when a guard fails. Those guards require clientInfo.issuer to be a string and tokens.expires_at/tokens.expiresAt to be finite numbers. vault set checked none of the three, so a typo in one field silently discarded everything next to it, and the command still printed Saved OAuth credentials.

clientInfo.issuer was covered incidentally by the old string-only rule, so the per-field table has to keep covering it. It is worth naming because vault set is the only writer of that field and its only consumer is a security check: assertRefreshIssuerBinding (src/oauth-token-refresh.ts:86) pins refresh to the recorded issuer, and an unusable value turns the pin into a no-op. tokens.expires_at and expiresAt are the pre-existing half, folded into the same loop as expires_in.

Deliberate tightening: client_id is now required

Today {"clientInfo": {}} is accepted. Both members of OAuthClientInformationMixed require client_id, so the existing as OAuthClientInformationMixed cast does not hold for that value. And {} is not read downstream as "no client information": it is a truthy object that saveVaultEntry persists and getClientInformation() later hands back in place of the statically configured client, so the failure surfaces much later as an opaque SDK error during refresh. clientIdFromEntry (src/oauth-vault.ts:302) and same-URL credential inheritance both need it too. This does make the write side stricter than isStoredOAuthClientInformation, which does not require client_id, and it is a behavior change, so I would rather flag it than bury it. It is one if plus one test case if you would rather not take it.

Two adjacent fixes in the same input path

• JSON.parse at line 47 was unguarded, so an unparsable payload left the command as a raw SyntaxError and printed a stack trace through the unexpected-error path instead of the usage path every other payload problem already uses. It now fails as a CliUsageError naming the source. The message deliberately does not repeat the parser's reason: V8 quotes a prefix of the input (Unexpected token 's', "sk-live-9f"... is not valid JSON), and the input here is credential material that can end up in a CI log. Naming the file follows src/cli/call-arguments.ts:373.
• The vault set help text showed clientInfo as client_id alone, which reads as the whole contract and is plausibly where the expectation in the issue came from. It now says a full registration response is accepted.

Behavior proof

The real CLI through tsx src/cli.ts, throwaway XDG_CONFIG_HOME and XDG_DATA_HOME, and the payload from the issue verbatim. The access token is fake and https://example.test/mcp is never contacted.

=== BEFORE (main @ 764bb87) ===
--- mcporter vault set demo --stdin
[mcporter] Vault payload clientInfo.redirect_uris must be a string.
--- stored vault entry
(no credentials file written)
--- mcporter vault set demo --stdin  (truncated JSON)
[mcporter] Unexpected end of JSON input
SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)

=== AFTER (this branch) ===
--- mcporter vault set demo --stdin
Saved OAuth credentials for 'demo' to <temp>/mcporter/credentials.json
--- stored vault entry
{
  "tokens": {
    "access_token": "fake",
    "token_type": "Bearer",
    "__mcporter_generation": "a344f320-3658-4b95-b6b4-972186d02740"
  },
  "clientInfo": {
    "client_id": "abc",
    "redirect_uris": [
      "https://example.test/cb"
    ],
    "grant_types": [
      "authorization_code"
    ],
    "response_types": [
      "code"
    ],
    "token_endpoint_auth_method": "none",
    "__mcporter_client_generation": "8468dd59-b501-47ff-a77e-7a76f3b471ab"
  }
}
--- mcporter vault set demo --stdin  (truncated JSON)
[mcporter] Vault payload from stdin is not valid JSON.

Same harness for the guard mismatch, reading the entry back through loadVaultEntry so the read-path guards actually run:

=== BEFORE (main @ 764bb87) ===
--- tokens.expires_at = "soon"
Saved OAuth credentials for 'demo' to <temp>/mcporter/credentials.json
    loadVaultEntry: (entry carries neither tokens nor clientInfo)
--- clientInfo.issuer = 42
[mcporter] Vault payload clientInfo.issuer must be a string.
    loadVaultEntry: (no vault entry)

=== AFTER (this branch) ===
--- tokens.expires_at = "soon"
[mcporter] Vault payload tokens.expires_at must be a finite number.
    loadVaultEntry: (no vault entry)
--- clientInfo.issuer = 42
[mcporter] Vault payload clientInfo.issuer must be a string.
    loadVaultEntry: (no vault entry)

The first case is the silent loss: the command reports success and the credentials are unreadable. The second is the one the old rule already caught and the new table has to keep catching.

Tests

tests/vault-validation.test.ts goes from 16 to 32 cases, in the table-driven style the file already uses:

• accepts a dynamic client registration clientInfo payload — the issue's payload verbatim.
• accepts registration timestamps, contacts, and a jwks document — client_secret, client_id_issued_at, client_secret_expires_at: 0, contacts, and a jwks document. Both acceptance cases assert the stored entry through loadVaultEntry, not the input object, so a dropped clientInfo fails the test.
• preserves unknown clientInfo fields and seeded token expiry — issuer, registration_client_uri, registration_access_token, tokens.expires_at and id_token all reach the vault verbatim. This is the case that fails if anyone later swaps the validator for one that reparses the payload.
• persists null clientInfo fields verbatim — the pre-0.12.1 null tolerance, held in place.
• rejects malformed clientInfo — a non-string entry inside redirect_uris, redirect_uris and grant_types given as bare strings, client_id_issued_at and client_secret_expires_at given as strings, a non-string client_name, a non-string issuer, and clientInfo with no client_id.
• rejects malformed payload — the existing rows plus tokens.expires_at and tokens.expiresAt given as strings.
• reports malformed stdin JSON as a usage error without echoing the payload and names the file when its JSON is malformed — one per input source.

Reverting only src/cli/vault-command.ts to main and keeping the tests:

=== tests against the unpatched validator ===
 FAIL  rejects malformed payload 6            (tokens.expires_at)
 FAIL  rejects malformed payload 7            (tokens.expiresAt)
 FAIL  rejects malformed payload 9            (clientInfo.client_id message)
 FAIL  reports malformed stdin JSON as a usage error without echoing the payload
 FAIL  names the file when its JSON is malformed
 FAIL  accepts a dynamic client registration clientInfo payload
 FAIL  accepts registration timestamps, contacts, and a jwks document
 FAIL  rejects malformed clientInfo 0         (redirect_uris entry)
 FAIL  rejects malformed clientInfo 1         (redirect_uris as string)
 FAIL  rejects malformed clientInfo 2         (grant_types as string)
 FAIL  rejects malformed clientInfo 3         (client_id_issued_at)
 FAIL  rejects malformed clientInfo 4         (client_secret_expires_at)
 FAIL  rejects malformed clientInfo 7         (missing client_id)
      Tests  13 failed | 19 passed (32)

The other 19 pass on both sides and cover what this change must not alter, including rejects malformed clientInfo 6, the issuer case.

One committed expectation moved: the row asserting clientInfo.client_id must be a string for client_id: 42 now expects must be a non-empty string, matching tokens.access_token.

Gates

Windows 11, Node 22.20.0, pnpm 10.33.2.

• pnpm exec vitest run tests/vault-validation.test.ts tests/vault-command.test.ts — 37 passed.
• pnpm check — oxfmt, type-aware oxlint and tsc --noEmit clean.
• pnpm build — clean.
• pnpm test — 1283 passed, 84 skipped, 7 failed. The 7 are in tests/chrome-devtools-relay-handoff.test.ts and tests/runtime-chrome-relay-handoff.test.ts, and they fail identically on unmodified main at 764bb87 on this machine (Invalid URL from the relay handoff), so they predate this branch and touch nothing it changes. I could not clear them here because this box is below the engine floor the repo declares (node >=24). CI settles it: build passes on ubuntu-latest, macos-15 and windows-latest for this branch.

Thanks @feniix for the report. The version table and the pointer straight at the validator left nothing to guess.