Approve a pending CLI device session (session cookie required)

POST/api/cli/login/sessions/{session_id}/approve

approveCliLoginSession

Session-authenticated caller only. Approves the pending CLI login or exact SSH-key enrollment. Requires sudo-mode unless the account has no step-up credential yet.

Requires authentication using a session cookie — see tokens and scopes.

curl

curl -X POST 'https://neosource.dev/api/cli/login/sessions/SESSION_ID/approve' \
  -b 'ns_session=$NEOSOURCE_SESSION' \
  -H 'Content-Type: application/json' \
  -d '{}'

fetch

fetch("https://neosource.dev/api/cli/login/sessions/SESSION_ID/approve", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  credentials: "include",
  body: JSON.stringify({}),
});

Path parameters

session_idrequired: CLI login session ID.
string

Request body

application/json

one of

null
ApproveCliLoginSessionRequest
Proof carried by the browser when approving a CLI device session. The empty-body form remains accepted by the server for old login pages and is interpreted as `keyless`. New pages send `exact_key` whenever the status response displayed a key, so approval is bound to the canonical algorithm/fingerprint/public-key tuple the user actually saw.
one of
- object
  Approve the login without authorizing SSH-key enrollment. This is the compatibility path for an old cached browser page.
  proofrequired
  string
  "keyless"
- object
  Approve the exact canonical key shown in the browser.
  algorithmrequired
  string
  Canonical SSH algorithm shown by the session status endpoint.
  fingerprintrequired
  string
  Canonical SHA-256 fingerprint shown by the session status endpoint.
  proofrequired
  string
  "exact_key"
  public_keyrequired
  string
  Canonical OpenSSH public-key line shown by the session status endpoint.

Responses

200Approval redirect URL

application/json

ApproveCliLoginSessionResponse

object

approvedrequired: boolean

403Forbidden — one of: forbidden, sudo_required

application/json

one of

ErrorForbidden
SudoRequiredError
object
Wire shape of the 403 a sudo-gated endpoint returns when sudo is missing or expired. `challenge` tells the SPA which sudo-prove endpoint to call.
challengerequired
string
Which sudo-prove endpoint the account should use: `"passkey"` (`/api/auth/sudo/passkey/{start,finish}`), `"password"` (`/api/auth/sudo/password`), or `"totp"` (`/api/auth/sudo/totp`), chosen from the account's registered credentials — passkey first when present, since it is both the strongest credential and the least friction. A hint for which prompt to show first, not an authorization decision: each sudo route verifies its own credential regardless of what was advertised here, so a client may use a different one.
errorrequired
string
Always `sudo_required` — this body exists to carry the extra fields that kind needs.
"sudo_required"
messagerequired
string

Standard errors

Bodies documented once for the whole API — see standard errors.

400Bad Request — one of: invalid_input
401Authentication required
404Not Found — one of: not_found
409Conflict — one of: already_exists, conflict
429Rate limited — retry after the `Retry-After` header
500Internal server error
503Service temporarily unavailable / at capacity — retry after the `Retry-After` header
504Gateway timeout — the request exceeded the server's handling budget