feat: headless provision subcommand + --ci --signup for agents#415
Open
feat: headless provision subcommand + --ci --signup for agents#415
Conversation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Extends the headless provision subcommand:
- --json flag (auto-enabled when stdout is not a TTY) emits the full
ProvisioningResult as a single JSON object to stdout; human log lines
go to stderr so they don't corrupt piped output.
- --name flag forwards to provisionNewAccount (previously hardcoded to "").
- Output now includes accountId, accessToken, refreshToken alongside
projectApiKey, host, projectId, personalApiKey.
- Errors in --json mode are emitted to stderr as {error, code}, with
code="email_exists" when the address is already registered so scripts
can branch without string-matching.
- README gains a "Headless Provisioning" section with usage examples and
a warning that output contains live credentials.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Covers the behaviors guaranteed by the spec: - --email is required (exit 1, API not called) - --region is uppercased before provisionNewAccount is invoked - --name forwards through as the name argument - --json emits one JSON object of the full ProvisioningResult on stdout - JSON mode auto-enables when stdout is not a TTY - human-readable mode routes through LoggingUI on console.log - email-already-associated rejections surface code: "email_exists" - other errors surface code: "provisioning_failed" Mocks provisionNewAccount and follows the existing cli.test.ts pattern for bin.ts loading. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Wires the headless signup path into the existing --ci install flow so a cold-start agent can bootstrap an account AND install PostHog into a project with a single command, no TTY, no browser, no prior API key. - Adds --email and --name to the $0 command (scoped, not global — global placement broke cli.test.ts mocking via a yargs parse-order quirk). - Relaxes the CI api-key gate: if --signup is set, provision first via provisionNewAccount(email, name, region), then set options.apiKey to the returned personalApiKey and options.projectId before falling through to runWizardCI. - --api-key takes precedence over --signup when both are supplied. - Surfaces clear errors for --ci without key-or-signup, and for --ci --signup without --email. - README: new "Headless signup + install" section for the combined flow; existing provision section preserved as a primitive. - Tests: new --ci --signup flow describe block in cli.test.ts covering success, --name forwarding, region uppercasing, rejection handling, missing personal API key, and --api-key precedence. The block uses a silent process.exit mock because the exits happen inside the async provisioning IIFE and the throwing mock would escape as an unhandled rejection. Mock variables renamed to per-file suffixes since .test.ts files share TS project scope when they have no imports/exports. Co-Authored-By: Claude Opus 4.7 (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. |
…dless-signup-install
edwinyjlim
approved these changes
Apr 28, 2026
Comment on lines
+188
to
+192
| email: { | ||
| describe: | ||
| 'Email for account creation with --ci --signup\nenv: POSTHOG_WIZARD_EMAIL', | ||
| type: 'string', | ||
| }, |
Member
There was a problem hiding this comment.
I think we can remove since email is defined in the global options
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
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
The wizard has no headless signup path. The interactive
$0flow requires a TTY + browser, and--cirequires a personal API key the caller already has. Neither works for a cold-start agent that needs to bootstrap PostHog into a project in one shot.Changes
Two layered entry points:
1.
wizard provisionsubcommand — a primitive that callsprovisionNewAccount()directly and emits the structuredProvisioningResulton stdout. No TUI, no framework detection, no browser. For tests, pre-flight checks, or callers that want credentials without the install.Failure exits 1; in
--jsonmode errors surface on stderr as{"error":"...","code":"..."}with a stableemail_existscode for the already-registered case.2.
wizard --ci --signup --email you@example.com --install-dir .— the end-to-end flow. The$0CI branch provisions a new account viaprovisionNewAccount, setsoptions.apiKey = result.personalApiKey, then falls through to the existingrunWizardCIinstall.--api-keytakes precedence if both are supplied.Also adds
--emailand--nameoptions (scoped to$0, not global — global placement broke the existingcli.test.tsmocking setup via a yargs parse-order quirk).Test plan
src/__tests__/provision-cli.test.ts— 8 tests covering the subcommand (required --email, region uppercasing, --name forwarding, JSON shape, auto-JSON for non-TTY, human-readable mode, email_exists error code, provisioning_failed error code).src/__tests__/cli.test.ts— new--ci --signup flowdescribe block with 7 tests (missing --email, missing key + no signup, success path sets apiKey, --name forwarding, region uppercasing, provisioning rejection, --api-key precedence).us.posthog.com: bothprovision --jsonand--ci --signupproduce valid credentials and the latter reaches the install flow.Dependency note:
--ci --signupneeds the server-side provisioned PAT to have working scopes. Tracked in PostHog/posthog#56029 — the wizard side works as soon as that PR merges (without it, the install reachesdetectRegionFromTokenand fails because the PAT has no scopes).Authored with Claude Opus 4.7 (1M context). Tests passed locally and I verified the real-API flow against us.posthog.com; I'm an agent and did not run the full CI locally.