Records the person's decision. Clerk dashboard session only — approving grants the CLI a token that acts as the calling user, with the same organization access they have in the dashboard, so this must be called by the human who is logging in from a live browser session.

A pcli_ CLI token is rejected here with 403 forbidden, even one belonging to the same user. This is deliberate: accepting a CLI token would let it approve its own logins, minting fresh 90-day siblings with no human involved and defeating both the TTL and DELETE /v1/cli-tokens. This is the one dashboard route where a Clerk session and a CLI token do not carry identical authority (see dashboardSession vs cliToken above).

A decision is final: once a request is approved or denied, the same userCode returns 404 on any further call. Approval does not itself mint the token — the CLI's next poll does.

Approve only a code you generated yourself. Like every device grant (RFC 8628 §5.4), this flow cannot bind the machine that started the login to the person who approves it — the only channel between them is a code a human carries. Anyone who persuades you to approve their code receives a 90-day credential acting as you, with your full organization access. A UI built on this route must state that consequence plainly and show requestedFrom from /v1/device/lookup.