feat: add provisioning API signup flow for new users#377
Open
feat: add provisioning API signup flow for new users#377
Conversation
When --signup is used, the wizard now creates a PostHog account via the agentic provisioning API with PKCE auth instead of opening a browser. Prompts for email in the terminal, then calls account_requests -> oauth/token -> resources to get credentials without any browser redirect. Falls back to browser OAuth login if the email already has an account. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
🧙 Wizard CIRun the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands: Test all apps:
Test all apps in a directory:
Test an individual app:
Show more apps
Results will be posted here when complete. |
- Replace readline prompt with --email CLI arg (avoids TUI/stdin conflict) - Add 30s request timeouts to all provisioning API calls - Use parseInt instead of Number for projectId - Thread email through session -> getOrAskForProjectData -> askForProvisioningSignup - Add email to WizardOptions type and CLI args Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
edwinyjlim
reviewed
Apr 7, 2026
Member
There was a problem hiding this comment.
oh hell yeah, top of funnel is getting exciting!
@MattBro i'm assuming the PKCE and account provisioning API endpoints aren't merged to the monorepo yet?
if the wizard has no credentials, ask "Create account or log in?" and prompt for email inline
for sure, we can build the UX/UI sign up flow in the TUI once that you have all the auth plumbing deployed
6 tests covering: full PKCE flow, existing account handling, API errors, resource provisioning failure, region parameter, request timeouts. Also fixes missing timeout on resources request. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
buildSession in the TUI path was missing the email arg, so --signup --email would fail in interactive mode. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Was using POSTHOG_DEV_CLIENT_ID in dev mode which doesn't match the ProvisioningPartner record created by the data migration. The provisioning client_id is always 'posthog-wizard' regardless of env. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Wire --region parameter through to provisioning (was hardcoded to US) - Add NaN guard on parseInt for projectId - Region threaded: CLI arg -> session -> getOrAskForProjectData -> provisionNewAccount Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
edwinyjlim
approved these changes
Apr 8, 2026
Member
edwinyjlim
left a comment
edwinyjlim
left a comment
There was a problem hiding this comment.
let's goo
feel free to merge once the monorepo endpoints are live
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When users run the wizard with
--signup, it opens a browser to posthog.com/signup. This requires browser access and creates friction for CLI-first workflows. Users should be able to create a PostHog account entirely from the terminal.Changes
src/utils/provisioning.ts- client for the agentic provisioning API using PKCE authsrc/utils/setup-utils.ts- when--signupis used with--email, creates account via provisioning API instead of browser OAuth--emailCLI arg and session fieldHow the PKCE flow works
npx @posthog/wizard --signup --email user@example.comPOST /api/agentic/provisioning/account_requestswith PKCE code_challengePOST /api/agentic/oauth/tokenwith code_verifierPOST /api/agentic/provisioning/resourcesFuture UX improvement
We should experiment with removing the
--signupflag entirely and auto-detecting: if the wizard has no credentials, ask "Create account or log in?" and prompt for email inline. This would make the defaultnpx @posthog/wizardflow work for new users without any flags. Keeping--emailas a CI shortcut.How did you test this code?
Tested end-to-end against local PostHog dev server running PostHog/posthog#53493 (server-side provisioning changes):
Agent-authored: full e2e test above was run, but no manual interactive TUI testing yet.
Depends on
PostHog/posthog#53493 (server-side ProvisioningPartner model + PKCE support)
Publish to changelog?
No (not ready yet - needs server-side PR merged first)
🤖 LLM context
Co-authored with Claude Code. Part of Slice 1 of the generic provisioning spec - making agentic provisioning multi-tenant so the wizard can create accounts via PKCE.