Problem

Setup-form answers were stored in two different places depending on how a credential was created:

Readers had to check both. Azure read configuration.resourceName ?? metadata.resourceName, and Snowflake did the same for account. Keys imported from V1 already kept their answers in metadata.

Change

configuration is removed from the public credential contract. Key credentials store their form answers in metadata, as external and OAuth credentials already do.

 Credential.Value =
-  | { type: "key",      key, metadata?, configuration? }
+  | { type: "key",      key, metadata? }
   | { type: "oauth",    methodID, access, refresh, expires, metadata? }
   | { type: "external", methodID, metadata? }

• integration.ts: the key connect flow writes the answer to metadata.
• model-resolver.ts: merges only metadata into provider settings, as it already did for every other credential type.
• Azure and Snowflake read metadata only.
• OpenAPI, the generated clients, the API, and plugins no longer have configuration.

Existing data

There is no database migration. Only two readers still accept the old shape, through @opencode/schema/credential-legacy, a storage and import schema that is not part of the public contract:

stored credential row  ──► Credential store decode  ──► CredentialLegacy.Value
auth export file       ──► CLI `auth import`        ──► CredentialLegacy.Entry ──► POST /api/credential (current shape)

CredentialLegacy merges a legacy configuration into metadata. When both share a key, the form answer wins, matching their old precedence in provider settings. Everything else uses Credential.Value, which treats configuration as an unknown key.

Compatibility

• Saved credentials keep working. They decode in memory and stay in their stored shape.
• auth export files from earlier releases keep their answers on auth import.
• Direct POST /api/credential calls that still send configuration: the field is ignored. Those calls should send form answers as metadata.
• Plugins and the Effect client: Credential.Key no longer has configuration. Read and write form answers in metadata.
• Downgrades to v2.0.25 and later: answers in metadata keep working there. Those releases merge metadata into provider settings for every credential type, and Azure and Snowflake fall back to metadata.
• Downgrades to v2.0.0 through v2.0.24: those releases also merge key-credential metadata into the request body (azure: migrated resourceName is rejected as unknown_parameter #53443, fixed in fix(core): stop sending API key metadata as request body #53546). A key credential created by this release can therefore send its form answers as request parameters there. Azure in those releases also reads an API-key credential's resource only from configuration, so Azure API-key credentials created by this release lose their resource name there. Credentials saved before upgrading are unaffected.

Verification

• packages/schema/test/credential-legacy.test.ts checks that:

  • legacy configuration merges into metadata with answers taking precedence;
  • current values and export entries pass through;
  • an invalid legacy configuration is rejected;
  • the public Credential.Value ignores configuration.

• packages/core/test/credential.test.ts "reads key form answers stored in configuration before v2.1 as metadata": inserts a legacy row with raw SQL. It fails when the store decodes with Credential.Value.

• packages/cli/test/auth.test.ts "imports credentials exported before v2.1 with their form answers as metadata": fails when auth import decodes with Credential.Entry.

• Tests:

  Package	Command	Result
  core	bun test test/credential.test.ts test/integration.test.ts test/model-resolver.test.ts test/plugin	490 pass
  schema	bun test	85 pass
  server	bun test	85 pass
  cli	bun test test/auth.test.ts test/import-export.test.ts	18 pass
  client	bun test	229 pass

• Typecheck: bun typecheck passes in schema, protocol, core, client, cli, server, sdk, tui, plugin, and app, apart from errors already on v2.1.

• Generated files: check:generated passes in packages/protocol, packages/client, and services/www.