Skip to content

fix(cli): surface actionable errors for cloud-mode setup failures - #1058

Open
danfinn5 wants to merge 1 commit into
PerpetualSoftware:mainfrom
danfinn5:fix/cloud-mode-error-messages
Open

fix(cli): surface actionable errors for cloud-mode setup failures#1058
danfinn5 wants to merge 1 commit into
PerpetualSoftware:mainfrom
danfinn5:fix/cloud-mode-error-messages

Conversation

@danfinn5

@danfinn5 danfinn5 commented Aug 3, 2026

Copy link
Copy Markdown

What does this PR do?

When a user picks Cloud mode during pad init but hasn't signed up for Pad Cloud, the CLI hits app.getpad.dev and surfaces raw server errors -- typically "Missing CSRF token" -- instead of telling the user what actually went wrong. This happened to me on a fresh Fedora 43 install; I spent a while debugging what I assumed was a server-side CSRF bug before realizing the CLI was talking to a remote server I had no account on.

Three small changes:

  1. printSetupRequiredHint now has a dedicated Cloud branch -- tells the user to sign up at app.getpad.dev/register or switch to local mode, instead of the generic "run pad auth setup on the server" message.
  2. pad init returns a cloud-specific error ("Pad Cloud account required") when setup_required is true in Cloud mode.
  3. The CLI HTTP client intercepts csrf_error responses and replaces the raw server message with "Session authentication error. Run pad auth login to re-authenticate." The CLI uses Bearer auth exclusively, so a csrf_error always indicates a session state problem, not something the user can act on directly.

Closes #1057

How to test

  1. pad auth configure --mode cloud (or pick Cloud during pad init)
  2. Without a Pad Cloud account, run pad init
  3. Should now see the sign-up URL and local-mode fallback instead of "Missing CSRF token"

Checklist

  • make build passes
  • make test passes
  • New features have tests (if applicable)
  • TypeScript types updated (if API changed)
  • CLI help text updated (if new command)

When a user picks Cloud mode during `pad init` but doesn't have a Pad
Cloud account, the CLI hits the cloud server and surfaces raw server
errors like "Missing CSRF token" — which is an implementation detail
that gives no indication of what went wrong or how to fix it.

This patch:

- Splits the ModeCloud and ModeRemote branches in printSetupRequiredHint
  so cloud users see "sign up or switch to local" instead of the generic
  "run pad auth setup on the server" message.
- Returns a cloud-specific error from pad init when setup_required is
  true in cloud mode.
- Intercepts csrf_error responses in the CLI HTTP client and replaces
  the raw server message with an actionable "run pad auth login"
  message, since the CLI never sends CSRF cookies and this error always
  indicates a stale or mismatched session.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CSRF token missing during init on Linux (browser, --cli-prompt, and headless)

1 participant