Independent reproduction confirms — applying this patch fixes the issue end-to-end.

Repro before fix (gbrain v0.30.0, vanilla):

OAuth client registered via SQL with scope='read', grant_types=['authorization_code','refresh_token'], public (PKCE-only, client_secret_hash=NULL). PKCE-public sidesteps a separate plaintext-vs-hash bug in confidential-client auth (#720, addressed by #746) — this lets the auth_code path actually exchange tokens.

Hit /authorize?...&scope=admin+read+write+sources_admin+users_admin&..., exchange code at /token:

{
  "scope": "admin read write sources_admin users_admin"
}

whoami confirms all 5 scopes. put_page (write) succeeds — probe page lands. get_stats (admin) returns full stats. Read-only client became fully admin-equivalent.

After cherry-picking this PR:

Same probe with the same client + same scope=admin+read+write+sources_admin+users_admin URL → token comes back with "scope":"read" only. put_page rejected with insufficient_scope. Contract holds.

bun test test/oauth.test.ts clean (64/64 pass), bun run typecheck clean.

Context: I was wiring gbrain into Claude Code as a read-only MCP transport for an Obsidian-vault sovereignty contract — the auth_code grant is the path Claude Code's MCP HTTP transport defaults to, so this clamp is what makes the read-only registration actually mean "read-only." The asymmetry the PR description calls out (exchangeClientCredentials already clamps; authorize() didn't) was visible in the wild — client_credentials tokens narrowed correctly while auth_code tokens didn't, against the same client.

Happy to land this so we can drop the local vendor branch. Thanks for catching it, @garagon.

Overall LGTM — ships a real bug, comment + tests make the intent durable. Two notes before garrytan picks it up, one substantive, one a cheap test addition.

1. Filter mirrors exchangeClientCredentials, but the omit-scope branch doesn't

The PR frames this as "all three grant entry points clamp consistently." For the filter step, yes. But the omit-scope branch leaves a residual asymmetry:

// exchangeClientCredentials, line 517-519
const requestedScopes = requestedScope ? parseScopeString(requestedScope) : allowedScopes;
//                                                                          ^^^^^^^^^^^^^

// this PR, authorize()
const grantedScopes = (params.scopes || []).filter(s => hasScope(allowedScopes, s));
//                    ^^^^^^^^^^^^^^^^^^^^

When the client omits ?scope= entirely:

• client_credentials → grants client.scope as default
• authorize() after this PR → grants []

Not a security boundary (erring restrictive is the safe side), and the PR description acknowledges it as existing shape. But RFC 6749 §3.3 says the AS MUST "process using a pre-defined default value or fail" — granting [] lands at "succeed and issue a token that fails every op with insufficient_scope," which is the worst UX of the three options. Concretely surfaces in clients that don't always include scope= (ChatGPT MCP connector flow). Suggest closing this in the same PR for true symmetry:

const requestedScopes = (params.scopes && params.scopes.length > 0)
  ? params.scopes
  : allowedScopes;
const grantedScopes = requestedScopes.filter(s => hasScope(allowedScopes, s));

2. Worth pinning hierarchy through this filter

The two new tests cover clamp + subset. They don't pin that `hasScope`'s `admin → {admin, sources_admin, users_admin, write, read}` hierarchy still fires through this filter — without a pin, a future refactor that swaps `hasScope` for `Set.has` would silently break admin-client-requests-read flows. Suggest:

```ts
test('authorize honors hierarchy — admin client can mint read-only token', async () => {
// client.scope = 'admin', params.scopes = ['read']
// expect auth.scopes === ['read']
});
```

Thanks for catching this — happy to land both for the cleanup.