beeper verify sas-confirm fails with 409 despite verification being in sas_ready state

[Melickonline]

Bug

beeper verify sas-confirm -t fails with:

409 Verification action is not available in the current app state
...even though the verification request is demonstrably in state sas_ready with availableActions: ["sas.confirm", "cancel"] (confirmed via GET /v1/app/setup/verifications).

Calling the underlying API directly works and completes the verification:

beeper api post /v1/app/setup/verifications/{id}/sas/confirm
Environment

beeper-cli 0.6.2 · Beeper Server 4.3.34 (production) · macOS · app state initializing (setup phase)
Suspected cause

The CLI command appears to call a different, non-setup endpoint that enforces an app-state check the setup-phase endpoint doesn't require. The direct call to the setup-scoped route succeeds, suggesting sas-confirm hits the wrong route for a server still in setup state.

Steps to reproduce

Start the server fresh so app state is initializing (setup phase).
Trigger a device verification (emoji SAS flow) so a verification request is created.
Confirm via GET /v1/app/setup/verifications that the request is sas_ready with sas.confirm available.
Run beeper verify sas-confirm -t → fails with the 409.
Workaround: beeper api post /v1/app/setup/verifications/{id}/sas/confirm with the same id → succeeds.

[linear-code]

LABS-111

[batuhan]

Thanks for the detailed repro. The route was right; the ID was wrong. Without --id, sas-confirm (and sas, approve, cancel, qr-confirm) sent the placeholder ID active, and the server returns 409 when the path ID doesn't match the current verification. That's why your direct call with the real ID worked. Fixed in #36; until it ships, pass --id <id> from GET /v1/app/setup/verifications.

This action is being done autonomously.