18 Commits

Author	SHA1	Message	Date
BilalG1	f7e389809e	feat(hexclave): PR 1 — wire compatibility layer (invisible) (#1475) ... ## Summary **Stacked on #1468** (`docs/hexclave-rename-plan` — the plan doc). Diff vs that base = the actual PR 1 code. This is **PR 1 of the Hexclave rebrand: the invisible compatibility layer**. Everything is additive. Old SDKs, old wire identifiers, and old env var names keep working unchanged. The backend dual-accepts and dual-emits; new SDK code emits `x-hexclave-*` headers and the `hexclave_` Bearer prefix; cookies dual-write; env vars dual-read across every category. **No user-visible rebranding lands here** — that's PR 2. See [`RENAME-TO-HEXCLAVE.md`](./RENAME-TO-HEXCLAVE.md) → *"PR 1 implementation guide"* for the full per-work-area spec, file pointers, and chosen approach. ## What's implemented (all 14 PR-1 work-areas) - **SDK export aliases** — `Hexclave*` aliases for the user-facing `Stack*` exports added in `packages/template`; codegen propagates them to `@stackframe/{js,stack,react,tanstack-start}`. React-only aliases correctly excluded from `@stackframe/js`. (`e60550a2`) - **JWT issuer dual-accept** — `decodeAccessToken` accepts both `api.stack-auth.com` and `api.hexclave.com` issuers. Signing unchanged. (`fc781def`) - **Request-header dual-accept** — backend + dashboard proxies normalize `x-hexclave-*` → `x-stack-*` at the existing empty proxy hook (so `smart-request.tsx` and every route schema keep working unchanged); CORS allowlists extended via a derive-once helper. (`2a056eac`) - **MCP `ask_hexclave`** — registered alongside `ask_stack_auth` via a shared helper; `ask_stack_auth` behavior byte-identical. (`30ffd604`) - **Dev-tool** — DOM ids + header emit switched. `window.HexclaveDevTool` exposed alongside `window.StackDevTool`. (`32131ea7`) - **The big consolidated commit** (`7fed864a`): - **Env vars** — central `getEnvVariable` prefix-transform (HEXCLAVE first, STACK fallback); dashboard + template client env files dual-read; `turbo.json` globalEnv; `NEXT_PUBLIC_STACK_PORT_PREFIX` renamed outright across ~82 files including docker. - **Cookies** — dual-write/dual-read auth (`stack-access`/`-refresh-*` and custom-domain variants), OAuth-state (`stack-oauth-{inner,outer}-*`), and low-risk cookies (`stack-is-https`, `stack-last-seen-changelog-version`). Bypass sites patched (backend OAuth callback, dashboard remote-dev auth route, impersonation snippets, snapshot serializer). - **Bearer prefix** — SDK token parser accepts both `stackauth_` and `hexclave_`; emits `hexclave_`. Discovery correction: this is purely SDK-internal — the backend never parses it. - **Response headers** — backend dual-emits `x-hexclave-{request-id,actual-status,known-error}`; SDKs dual-read (new first, stack fallback). - **SDK request-header emit switch** — `client/server/admin-interface.ts` + dashboard `api-headers.ts` + `internal-project-headers.ts` + `feedback-form.tsx` switched to `x-hexclave-*`. Plus `stack_response_mode` query param. - **Storage keys** — dev-tool / cli-auth / oauth-button / docs keys renamed (straight); `stack:session-replay:v1` dual-read so in-progress recordings survive SDK upgrades; `stack_mfa_attempt_code` dual-read. - **Query params** — cross-domain params dual-emit/dual-accept via shared helpers; backend `oauth/authorize` accepts `hexclave_response_mode` and `stack_response_mode`; `stack-init-id` renamed. - **`Symbol.for`** — app-internals symbol gets a parallel `Symbol.for("Hexclave--app-internals")` getter on each attach site (no read-site churn — old symbol still attached). 3 file-private symbols renamed outright. - **Config discovery** — prefer `hexclave.config.ts`, fall back to `stack.config.ts` at every discovery site (CLI / dashboard / backend / local-emulator); `init` writes the new filename; CLI credentials path migrates. - **Internal renames** — `StackAssertionError`, `StackClient/Server/AdminInterface` renamed outright (no alias, per the "internal-only → rename" rule). ~264 files touched. - **Review-pass fixes** (`21217fbe`) — three real bugs found by parallel review agents and fixed: - `snapshot-serializer.ts` was interpolating the whole `keyedCookieNamePrefixes` array (`${arr}`) — adding a second prefix would have corrupted **every** OAuth-cookie snapshot, not just new ones. - **Docker port-prefix producer/consumer mismatch** — `entrypoint.sh`/`run-emulator.sh`/cloud-init `user-data` were still producing `NEXT_PUBLIC_STACK_PORT_PREFIX` while the dashboard sentinel + consumers had been renamed; silent self-host regression (custom port prefix would be ignored). - **Missing `hexclave-oauth-inner-*` dual-write** in the OAuth authorize route — callback's fallback masked it but the dual-write was specified by the plan. - Plus: `mcp.test.ts` tool-list assertions updated to include `ask_hexclave`; two dashboard header-emit sites switched to `x-hexclave-*` for consistency. - **E2E snapshot serializer follow-up** (`4b16cc5d`) — `x-hexclave-request-id` added to the hidden-headers list (mirroring `x-stack-request-id` treatment), and 2 sample inline snapshots regenerated in `projects.test.ts` to include the new dual-emitted headers. ## Verification - **`pnpm typecheck`** — clean (the fresh-worktree `@/.source` / Prisma codegen gap in `stack-docs` is pre-existing and unrelated). - **`pnpm lint`** — 29/29 packages green. - **`pnpm exec turbo run build --filter=./packages/*`** — 13/13 packages build (including `@stackframe/stack-cli` once the dashboard standalone is present). - **Live E2E** against a running backend on `cl/hexclave-pr1`: - `pnpm test run apps/e2e/tests/backend/endpoints/api/v1/internal/mcp.test.ts` — **6/6 pass** (verifies the new `ask_hexclave` tool — the hand-written inline snapshot matched actual MCP server output). - `pnpm test run apps/e2e/tests/backend/endpoints/api/v1/internal/projects.test.ts` — **11/11 pass** (verifies wire dual-accept + dual-emit end-to-end; the snapshot serializer fix was found and applied during this check). A four-agent parallel **review pass** also audited the full diff for logic/runtime bugs across the work-areas (wire headers + JWT, cookies + bearer + symbols, env vars, query params + config + MCP + aliases). All in-slice review verdicts were ✓ except the three bugs listed above, which are now fixed. ## Known follow-ups (out of scope for this PR) - **E2E snapshots across the rest of the suite** — backend now dual-emits `x-hexclave-{known-error,actual-status}` alongside `x-stack-*`, which legitimately appears in inline snapshots throughout `apps/e2e`. Two were regenerated here as a sample; the rest should regen with `vitest -u` in CI. - **Docker shell env vars beyond `PORT_PREFIX`** — `entrypoint.sh` still reads `STACK_*` env vars directly (the JS-side `getEnvVariable` transform doesn't help the shell). JS consumers dual-read so it works in practice; full shell-level dual-read is a deeper self-host follow-up. - **`@stackframe/stack-cli` build ordering** — pre-existing; needs `build:rde-standalone` first. Not affected by this PR. ## Test plan - [ ] CI runs full e2e suite (with `vitest -u` to absorb dual-emit snapshot deltas, then committed back) - [ ] Spot-check: an old SDK build (emitting only `x-stack-*`) still authenticates against the new backend - [ ] Spot-check: a new SDK (emitting `x-hexclave-*` / `Bearer hexclave_*`) still authenticates against an old backend during deploy ordering - [ ] Manual: `npx @stackframe/stack-cli@latest init` (new onboarding entrypoint) generates `hexclave.config.ts` - [ ] Manual: existing `stack.config.ts`-only project still resolves (no migration required) --------- Co-authored-by: bilal <bilal@stack-auth.com>	2026-05-23 17:24:55 -07:00
BilalG1	01aacd2dd4	fix(dashboard): repair and polish the GitHub link-existing project flow (#1441) ... Rework of the **new-project → Link Existing Config** flow on the dashboard, plus the published `stack-cli` it depends on. The starting point on `dev` had the link-existing flow effectively broken end-to-end (the generated GitHub workflow could never authenticate, and the GitHub-account selection UI dead-ended in several states). This PR fixes the blockers, polishes the local-CLI path, and adds a searchable repo/branch picker. --- ## What was broken | Severity | Issue | Fixed in | |---|---|---| | 🔴 | Generated workflow omitted the required `--cloud-project-id` flag → every run failed at Commander before the action ran. | `d0e6ad15f`, `55ff7e319` | | 🔴 | Workflow exported `STACK_PROJECT_ID` env var the CLI never read. | `55ff7e319` (CLI now reads it; workflow drops the explicit flag) | | 🔴 | `pnpx` isn't on `ubuntu-latest` → step failed with `command not found`. | `65789a1ac` | | 🔴 | "No connected GitHub account found" alert with **no Connect button**. | `d0e6ad15f` | | 🟠 | "Connect new" used `getOrLinkConnectedAccount` (get-or-link) → silently returned the existing account instead of starting a fresh OAuth flow. | `d0e6ad15f` | | 🟠 | `workflow_dispatch` 404s on non-default branches; threw before advancing to the logs step even though the push-triggered run worked. | `d0e6ad15f` | | 🟠 | Config-path suggestions prepended `./`, which breaks GitHub's `on.push.paths` filter — ongoing config edits never re-triggered the workflow. | `d0e6ad15f` | | 🟡 | Account selector briefly showed the numeric `providerAccountId` before the GitHub `/user` fetch populated the username. | `de9ec1923` | | 🟡 | Repository / branch dropdowns capped at 100 entries with no search. | `7550eaacb` | ## What changed ### Dashboard — Link Existing Config flow - **Local CLI step rebuild** (`ed25eabf9`, `ebb090e5b`): split into separate "Sign in" and "Push config" code blocks using the shared `CodeBlock` component (copy button built-in), added a `npx / pnpx / bunx` runner pill toggle (default `npx`), moved `--config-file <path>` to the end of the push command so users can copy everything up to the placeholder, trimmed redundant helper text. - **GitHub OAuth states** (`d0e6ad15f`, `de9ec1923`): empty-state "Connect GitHub account" button; "Connect new" now uses `linkConnectedAccount` so it actually starts OAuth; loading row instead of `providerAccountId` flash. - **Searchable repo + branch combobox** (`7550eaacb`, `5ce1b6bd9`): new `RemoteSearchCombobox` (Popover + cmdk, same pattern as `data-table/faceted-filter`), debounced GitHub `/search/repositories` and `/git/matching-refs/heads/{prefix}` calls so users with > 100 repos/branches can find any of them. Branch "Refresh" button removed — branches auto-load on repo select. - **Workflow generator** (`d0e6ad15f`, `65789a1ac`): config paths normalised (strip leading `./`); workflow uses `actions/setup-node@v4` + `npx --yes`; `workflow_dispatch` failure is now best-effort (the workflow-file commit's push event triggers the run on any branch). ### Stack CLI - `STACK_PROJECT_ID` env-var fallback for `--cloud-project-id` (`55ff7e319`). Both `config push` and `config pull` are affected; explicit flag still wins. New `resolveProjectId` helper in `lib/auth.ts` with 5 unit tests (`auth.test.ts`). ### Misc - `2faffb662` drops an unused `useTransition` wrapper around a `setProjectStatuses` Map insert in the new-project flow. --- ## Release ordering note The generated workflow's `run:` line **no longer passes `--cloud-project-id`** — the CLI reads `STACK_PROJECT_ID` from env instead. This means a workflow generated by this branch only works against a `@stackframe/stack-cli` published with the env-var fallback from `55ff7e319`. The CLI and dashboard ship from the same monorepo so this should be a non-issue in the normal release cadence, but worth confirming the CLI publishes alongside the dashboard deploy. Existing workflows already committed in user repos still have the explicit flag and continue to work unchanged. ## Validation - `pnpm --filter @stackframe/dashboard run typecheck` ✅ - `pnpm --filter @stackframe/dashboard run lint` ✅ - `pnpm --filter @stackframe/stack-cli run typecheck` ✅ - `pnpm --filter @stackframe/stack-cli run lint` ✅ - `pnpm --filter @stackframe/stack-cli test` ✅ (14 tests; 5 new for `resolveProjectId`) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Searchable repository and branch selection UI for GitHub onboarding * New remote search combobox component for selecting repos/branches * Selectable CLI package runner and dynamic command display during onboarding * **Improvements** * CLI accepts STACK_PROJECT_ID env var; cloud project flag is optional * Workflow generation normalizes/validates config paths, sets up Node.js v20, and uses npx; onboarding dispatch is non-fatal * Hardened repository loading to avoid stale async updates * **Tests** * Added tests covering project ID resolution logic <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/hexclave/stack-auth/pull/1441?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-05-20 16:39:40 -07:00
Konsti Wohlwend	29cea48beb	Remote dev envs (#1435)	2026-05-19 15:54:18 -07:00
Konstantin Wohlwend	049c557a06	--config-file is now a file, not a folder	2026-05-15 15:54:54 -07:00
BilalG1	15faf709f3	stack-cli: explicit --cloud-project-id / --config-file across exec, config, project (#1422) ... ## Summary Reworks the `stack` CLI surface so the cloud-vs-local choice is **explicit at every invocation**, removing the global `--project-id` / `STACK_PROJECT_ID` env var and the local-default `exec` behavior introduced earlier in this branch. ### `stack exec` - Removes `--cloud`, `STACK_EXEC_DEFAULT_TARGET`, and the implicit local default. The CLI now requires **exactly one** of: - `--cloud-project-id <id>` — run against the Stack Auth cloud API - `--config-file <path>` — run against the local emulator project mapped to that absolute config-file path - The `--config-file` branch resolves the project id by calling the existing `GET /api/latest/internal/local-emulator/project` endpoint and matching `absolute_file_path` client-side. No new backend endpoint introduced. ### `stack config pull` / `stack config push` - Both now take `--cloud-project-id <id>` per-command instead of the global flag / `STACK_PROJECT_ID` env. - `config pull --config-file` is **optional**: when omitted, the CLI uses `./stack.config.ts` from the current directory. If neither flag nor cwd file is present, it exits with a clear hint to pass `--config-file` or `cd` into a directory containing `stack.config.ts`. ### `stack project list` - Default (no flags) lists both **cloud and local emulator** projects. Each entry carries a `target: "cloud" | "dev"` field (text format: `<id>\t<displayName>\t[<target>]`). - `--cloud` / `--dev` filter to a single source (mutually exclusive — passing both errors). - On the default code path, an unreachable local emulator emits a single stderr warning (`warning: skipping dev projects — local emulator not reachable …`) and the command still succeeds with cloud results. With `--dev` explicit, the unreachable case hard-errors. ### `stack project create` - Now requires `--cloud` to make the cloud-vs-local choice explicit. There is no local alternative today; the flag exists to surface the decision so a future local-project create doesn't silently change behavior. ### Backend - Bumps the `LIMIT` on `GET /api/latest/internal/local-emulator/project` from 20 → 100 so `project list --dev` doesn't silently truncate. ### Refactors (from earlier in this branch, unchanged here) - Local-emulator paths/ports/PCK polling live in `packages/stack-cli/src/lib/emulator-paths.ts`. - Shared local-emulator admin credentials live in `packages/stack-shared/src/local-emulator.ts`. - `resolveAuth` / `resolveLocalEmulatorAuth` take an explicit `projectId: string` (no more `Flags` parameter). - New `packages/stack-cli/src/lib/local-emulator-client.ts` encapsulates the GET-and-match flow used by both `exec --config-file` and `project list --dev`. ## Breaking changes **Scripts that relied on any of the following must be updated:** | Removed | Replacement | | --- | --- | | Global `--project-id <id>` flag | Per-command `--cloud-project-id <id>` | | `STACK_PROJECT_ID` env var | Per-command `--cloud-project-id <id>` | | `stack exec --cloud` | `stack exec --cloud-project-id <id>` | | `STACK_EXEC_DEFAULT_TARGET=cloud\|local` | `--cloud-project-id <id>` or `--config-file <path>` | | `stack exec` defaulting to local emulator | Explicit `--config-file <path>` required | | `stack project create` without a flag | `stack project create --cloud …` required | ## Test plan - [x] `pnpm lint` (stack-cli, backend, e2e) — clean - [x] `pnpm --filter @stackframe/stack-cli typecheck` — clean - [x] `pnpm --filter @stackframe/stack-cli exec vitest run` — **72/72 passing** (new unit tests: `parseExecTarget`, `resolveConfigFilePathForPull`, `resolveProjectListSources`, `formatProjectList`) - [x] `pnpm test run apps/e2e/tests/general/cli.test.ts` — **73 passing, 4 skipped, 0 failing**. New e2e cases cover: - `exec` with neither flag → errors with "Specify a target" - `exec` with both flags → errors with "not both" - `exec --config-file` with missing file / missing PCK / unreachable API - `exec --config-file` happy path against a real local-emulator backend (gated on `NEXT_PUBLIC_STACK_IS_LOCAL_EMULATOR=true`) - `config pull` cwd fallback to `./stack.config.ts` - `config pull` with no `--config-file` and no cwd `stack.config.ts` → errors with `Pass --config-file …` - `project list --cloud --dev` together → errors - `project list` default with unreachable emulator → cloud results + single stderr warning - `project create` without `--cloud` → errors - All previously-`--cloud` exec cases ported to `--cloud-project-id` - [x] Manual smoke: `stack exec --help`, `stack project list --cloud --dev`, `stack project create` all emit the expected friendly errors / help text. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **New Features** * CLI `exec`, `config`, and `project` commands now require explicit targeting via `--cloud-project-id` (cloud) or `--config-file` (local emulator). * `project list` now supports `--cloud` and `--dev` flags to display projects from both sources with target indicators. * Enhanced environment variable validation for emulator service ports with proper fallback handling. * **Bug Fixes** * `project list` now gracefully handles unreachable emulator with warning fallback instead of failure. * **Tests** * Expanded test coverage for project targeting, config file resolution, and emulator connectivity scenarios. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-05-14 17:20:40 -07:00
aadesh18	acc646cb0b	stack-cli: cloud/local init flow, auto-create on empty projects, post-setup next-steps (#1383) ... ### Summary Reworks `stack init` UX, adds Sentry error reporting to the CLI, polishes the emulator start flow, and overhauls the local-emulator dashboard's "Open config file" dialog. #### `stack init` flow - **New top-level flow.** Drops the old "link existing vs. create new local" fork. `init` now asks *where* to create the project — "Stack Auth Cloud" or "Local". Adds a new `create-cloud` mode that logs the user in, creates a cloud project, mints keys, and writes `.env` — no round-trip through the dashboard. - **Conditional emulator-install warning.** The "Local" choice label only shows "(requires local emulator installation, ~1.3gb storage required)" when the QEMU image isn't already on disk; otherwise it shows "(emulator already installed)". Driven by a new `isEmulatorImageInstalled()` helper in `commands/emulator.ts`. - **Auto-create on zero-projects.** When the link-from-cloud path hits an empty project list, the CLI now prompts *"You don't have any Stack Auth projects yet. Would you like to create one?"* and, on yes, runs the same flow as `stack project create`. Skips the pointless "select a project" prompt when we just created one. - **MCP-server notice.** Before invoking the coding agent, the CLI announces that it's also registering the Stack Auth MCP server (`mcp.stack-auth.com`) so the agent can answer Stack-specific questions going forward. - **Local-emulator env header.** When `writeProjectKeysToEnv` runs in `local` mode it writes a 3-line comment header above the keys explaining they're emulator-only and only valid while the emulator is running. - **"What's next" footer.** After setup finishes, prints a short orientation block: where the sign-up/sign-in routes live (`/handler/sign-up`, `/handler/sign-in`), how to start the local emulator (for `create` mode), a dashboard deep link for cloud projects (respects `STACK_DASHBOARD_URL`), and a docs link. #### Sentry error reporting (`lib/sentry.ts`, `index.ts`, `tsdown.config.ts`) - New `lib/sentry.ts` initializes `@sentry/node` with PII scrubbing (Stack key prefixes, JWTs, home-dir paths, sensitive field names like `token`/`secret`/`password`/`dsn`). - DSN is baked at build time via a tsdown `define` sentinel (`__STACK_CLI_SENTRY_DSN__`) — no DSN in source, no runtime env-var dependency for installed users. CI sets `STACK_CLI_SENTRY_DSN_BUILD` before `pnpm build`. - Disabled when `NODE_ENV=development` or `CI`. No user opt-out. - Wired into `main()`'s catch (only for unexpected errors — `CliError`/`AuthError` still print and exit cleanly) plus `uncaughtException` and `unhandledRejection` handlers via a `handleFatal` helper. #### `stack emulator start` welcome - After a fresh start (not when reusing a running VM, not when `--config-file` keeps stdout JSON-only), prints a short "Emulator is up" block with service URLs (dashboard / backend / inbucket) and common commands (`status`, `stop`, `reset`, `run`). #### Local-emulator dashboard "Open config file" dialog The dialog at `http://localhost:26700` (when no project is loaded) used to be a single text input asking for an absolute path, with no explanation of where that path comes from. **Backend** (`apps/backend/src/app/api/latest/internal/local-emulator/project/route.tsx`): - POST is now tolerant of directory paths or paths that don't end in `.ts`/`.js`/`.mjs` — it appends `stack.config.ts` and creates the file if missing (`writeConfigToFile` mkdir's parents). Lets users paste a project folder instead of hunting for the config file. - New GET endpoint returns up to 20 most-recent `LocalEmulatorProject` rows joined with their display names, sorted by `updatedAt` desc. Same `isLocalEmulatorEnabled()` + client-auth gating as POST. **Dashboard** (`apps/dashboard/src/app/(main)/(protected)/(outside-dashboard)/projects/page-client.tsx`): - Title changed to "Open your Stack Auth project". Description now explicitly ties the file to `stack init`: *"Point the local dashboard at the `stack.config.ts` in your project. If you just ran `stack init`, it was created at the root of that project."* - Added: *"Don't have one yet? Paste your project folder path instead and we'll create stack.config.ts for you."* - Recent-projects list (clickable rows that prefill the input) fetched from the new GET endpoint when the dialog opens. - OS-specific copy-path tip below the input (macOS ⌥-Copy as Pathname, Windows Shift+RC Copy as path, Linux `realpath`). - "Open project" button is disabled when the input is empty. - All error paths (empty input, non-absolute path, server errors, exceptions) surface via destructive toasts instead of throwing. Why no native file picker: browsers do not expose absolute filesystem paths from `<input type="file">`, drag-and-drop, or the File System Access API. The backend requires an absolute path, so a Finder-style picker isn't possible from a web page. The recent list + OS tips are the workaround. ### Goal The previous `init` flow dead-ended new users: if you had no project you got an error telling you to go create one in the dashboard and come back. The happy path also forced a choice between "link existing" and "create local emulator" — not the question most users are trying to answer. The emulator dashboard's open-project dialog had similar friction: an unexplained path field with no recall of previously-opened projects. And the CLI silently swallowed unexpected errors with no telemetry. This branch makes the first-run path work end-to-end from the terminal, gives the emulator dashboard a usable open-project surface, and turns CLI crashes into actionable bug reports. ### How to review - Start with `packages/stack-cli/src/commands/init.ts` — the whole user-facing flow lives in `runInit`. Mode dispatch at the top, `handleCreateCloud` is the new cloud branch, `printNextSteps` is the footer, the MCP notice prints right before `runClaudeAgent`. - `packages/stack-cli/src/lib/sentry.ts` is small and self-contained; the sentinel-replacement contract is in `tsdown.config.ts`'s `define` block. Confirm `dist/index.js` contains zero `__STACK_CLI_SENTRY_DSN__` occurrences after a build with the env var unset, and the actual DSN host after a build with it set. - `packages/stack-cli/src/commands/emulator.ts` — `printEmulatorWelcome()` is the welcome block; `isEmulatorImageInstalled()` is the new exported helper used by `init.ts`. - `apps/backend/src/app/api/latest/internal/local-emulator/project/route.tsx` — the directory-tolerance branch is in the POST handler around the `looksLikeConfigFile` check; the GET handler is appended at the bottom. - `apps/dashboard/src/app/(main)/(protected)/(outside-dashboard)/projects/page-client.tsx` — dialog markup, recent-list fetch effect, `pathCopyTip` memo, and the toast-based error handling in `handleOpenConfigFile`. - Non-interactive (CI) paths stay strict: empty-project list still errors with a pointer to `stack project create --display-name`. No surprise project creation in CI. - No tests. The CLI has no harness for the interactive flow; verification is manual. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Recent local emulator projects listed in the config dialog for quick selection. * New CLI create-cloud mode and --display-name flag; interactive cloud project creation and clearer next steps. * Emulator start shows a welcome banner with service URLs when a new instance starts. * **Improvements** * Config dialog UX, validation, error-toasting, and platform-aware copy refined; “Open project” disabled for empty/invalid paths. * CLI: centralized interactive project creation and improved fatal error handling. * **Chores** * Sentry added and initialized for CLI error reporting. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Bilal Godil <bg2002@gmail.com>	2026-05-08 10:47:49 -07:00
aadesh18	6eaf49237f	Add fix command registration and update agent UI label handling (#1387) ... Adds a fix command to the stack cli <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a CLI "fix" command to submit Stack Auth errors (flag, stdin, or interactive), confirm before applying changes, show a customizable progress label, and produce a final markdown report with Error, Files changed, and Solution. * Added a CLI "doctor" command to analyze projects (framework override, output directory, JSON output), run framework-specific checks, validate env and config, and exit non-zero on failures. * **Tests** * Added comprehensive end-to-end tests for the doctor command. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-05-07 18:33:43 -07:00
BilalG1	3b8667d5f8	cli add back init options (#1379) ... <!-- Make sure you've read the CONTRIBUTING.md guidelines: https://github.com/stack-auth/stack-auth/blob/dev/CONTRIBUTING.md --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a "create-cloud" mode to the CLI init flow. * New interactive project creation flow that can prompt for display name and select/create a team-backed project. * **Behavior Changes** * Init now resolves mode from flags, config, or interactive prompts; prompts to choose linking vs creating when inputs are missing. * Non-interactive runs now error when required inputs are absent; cloud linking offers auto-create in interactive mode. * **Refactor** * Centralized auth, project-creation, and env key writing for clearer, safer linking and creation flows. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: aadesh18 <110230993+aadesh18@users.noreply.github.com>	2026-04-27 11:45:44 -07:00
Bilal Godil	37e70ca1ae	rotate stack cli publishable client key	2026-04-22 18:58:27 -07:00
BilalG1	37ee5ec320	Fast-start local emulator via RAM snapshot + live secret rotation (#1340) ... ## Summary `stack emulator start` now resumes a fully-warm VM snapshot instead of cold-booting, bringing startup from 30–120s down to ~5–8s with per-install secret rotation, or ~2.5s with rotation opt-out. The snapshot is captured **locally on first `stack emulator pull`**, not shipped from CI — QEMU migration state isn't portable across accelerators (KVM/HVF/TCG) or `-cpu max` feature sets, so a CI-captured snapshot couldn't resume reliably on arbitrary user hardware. Also bundles a pile of CLI QoL fixes (progress bars, PR/run artifact pulls, PR-build download, native-TS ISO writer replacing `hdiutil`/`mkisofs`/`genisoimage` host dep, unit tests). | Scenario | Before | After | |---|---|---| | Cold boot (no snapshot) | 30–120s | same, works as fallback | | `stack emulator pull` (one-time, includes local snapshot capture) | ~30s download | ~30s download + ~1–3 min cold-boot capture | | Snapshot resume, normal start | — | **~5–8s** | | Snapshot resume, `EMULATOR_NO_ROTATION=1` | — | **~2.5s** | Backend (`/health?db=1`) and dashboard (`/handler/sign-in`) return 200 on all paths. Two successive snapshot resumes produce different rotated PCK/SSK/SAK/CRON_SECRET values per install. ## How it works **Build (CI)** — `docker/local-emulator/qemu/build-image.sh`: 1. Cloud-init provisioning runs to completion (migrations, seed, slim-image) producing `stack-emulator-<arch>.qcow2`. 2. Image is built with a topology compatible with later snapshot capture (pinned SMP=4, phantom seed/bundle ISOs, STACKCFG runtime ISO mounted at build time, qemu-guest-agent running, placeholder hex secrets baked in under `STACK_EMULATOR_BUILD_SNAPSHOT=1`). 3. CI publishes **only the qcow2** — no `.savevm.zst` ships. **Pull (user's machine)** — `packages/stack-cli/src/commands/emulator.ts` + `run-emulator.sh capture`: 1. `stack emulator pull` downloads the qcow2 with a progress bar (or from a PR / workflow run via `--pr` / `--run`). 2. CLI invokes `run-emulator.sh capture`: cold-boots the qcow2 with a matching device layout (phantom ISOs, fsdev, pcie-root-port, virtfs detached — migration-incompatible), waits for backend+dashboard health, then drives QMP: `stop` → set `mapped-ram` + `multifd` caps → `migrate file:state.raw` → poll `query-migrate` → `quit`. Raw mapped-ram file is zstd-compressed to `stack-emulator-<arch>.savevm.zst` in the images dir. 3. `--skip-snapshot` opts out (first `start` will then cold-boot). **Runtime** — `run-emulator.sh start`: 1. Launch QEMU with `-incoming defer` when a `.savevm.zst` is present; decompress on first use, keep the `.raw` cached for subsequent starts. 2. QMP: same `mapped-ram` + `multifd` caps → `migrate-incoming file:<.raw>` → poll for `paused` → `cont`. 3. Generate fresh per-install secrets on the host; pipe them base64-encoded through QGA `guest-exec input-data` → `trigger-fast-rotate` in the guest → `docker exec -e … rotate-secrets`. 4. `rotate-secrets` in the container: validate keys (hex-only), targeted `sed` on the placeholder PCK across built JS, `UPDATE ApiKeySet`, `supervisorctl restart stack-app cron-jobs` (with `stopasgroup`/`killasgroup` so the Node children actually die and release their ports). 5. Poll backend+dashboard health; if anything fails, clean up and fall back to cold boot transparently. **Security model**: placeholder hex values are baked into the snapshot (`00…ff` PCK, `00…ee` SSK, `00…dd` SAK, `00…cc` CRON_SECRET). They are non-secret by construction. Real per-install secrets are generated at each `emulator start` and never leave the host. ## CLI changes (`packages/stack-cli`) - **`src/lib/iso.ts`** (new): native TypeScript ISO 9660 + Joliet writer, replacing the host-side `hdiutil`/`mkisofs`/`genisoimage` dependency for generating the STACKCFG runtime config disk. Unit tests in `src/lib/iso.test.ts`. - **`src/commands/emulator.ts`**: - `pull`: streamed downloads with progress bar + ETA; `--pr <number>` and `--run <id>` to pull from a PR build's CI artifacts (uses `extract-zip` for the nested zip); `--skip-snapshot` to opt out of the one-time local capture. - `start` (existing, extended): auto-pulls AND auto-captures when no image exists, so first-ever `start` is self-bootstrapping; emits `STACK_EMULATOR_CLI_WROTE_ISO=1` so the shell helper skips its own ISO regen (avoids the genisoimage host dep). - `capture` (new, invoked by `pull` and the auto-pull path of `start`): drives the local snapshot capture via `run-emulator.sh`. - `status`, `stop`, `reset`, `list-releases`: preflight + path-resolution tightening (`STACK_EMULATOR_HOME` → images/run dirs). - Unit tests in `src/commands/emulator.test.ts`. - **`EMULATOR_NO_ROTATION=1`** env var skips the post-resume rotation (intended for tests/CI where the placeholder secrets are fine — comes with a loud warning). ## CI (`.github/workflows/qemu-emulator-build.yaml`) - Builds **QEMU 10.2.2 from source** (cached), because `mapped-ram`/`multifd` migration capabilities aren't available in the distro's QEMU. Enables KVM on ubicloud runners so amd64 boots at hardware speed. - amd64 + arm64 both build on the same amd64 matrix (`ubicloud-standard-8`); arm64 runs under cross-arch TCG (provisioning only — boot/verify smoke test is amd64-only). - Verification now runs through the CLI: `emulator start` → `emulator status` → `emulator stop` against the freshly-built qcow2 (via `STACK_EMULATOR_HOME` pointing at the workspace, so the CLI doesn't silently auto-pull a prior release). - Packages **only** the qcow2. No `.savevm.zst` upload / publish. - Release notes updated. ## Key files **Shell / guest:** - `docker/local-emulator/qemu/build-image.sh` — snapshot-compatible device topology + STACKCFG runtime ISO at build time - `docker/local-emulator/qemu/run-emulator.sh` — `start`, `capture`, `stop`, `reset`, `status`; `-incoming defer`, `.raw` cache, QGA-driven rotation, cold-boot fallback - `docker/local-emulator/qemu/common.sh` (new) — shared `qmp_session` + `capture_vm_state` (factored out so build-image.sh and run-emulator.sh share the capture path) - `docker/local-emulator/qemu/cloud-init/emulator/user-data` — placeholder secrets in snapshot mode, `wait-for-stack-ready`, `trigger-fast-rotate`, qemu-guest-agent enabled - `docker/local-emulator/rotate-secrets.sh` (new) — in-container rotation (sed + UPDATE + supervisorctl) - `docker/local-emulator/supervisord.conf` — `stopasgroup`/`killasgroup` on `stack-app` and `cron-jobs` - `docker/local-emulator/entrypoint.sh` — only mint CRON_SECRET if unset (placeholder supplied in snapshot mode via --env-file) - `docker/local-emulator/Dockerfile` — ships `rotate-secrets` to `/usr/local/bin` - `docker/server/entrypoint.sh` — source `/run/stack-auth/rotated-secrets.env`; skip full-tree sentinel scan on warm restarts via marker **CLI:** - `packages/stack-cli/src/lib/iso.ts` (new) + `iso.test.ts` (new) - `packages/stack-cli/src/commands/emulator.ts` + `emulator.test.ts` (new) - `packages/stack-cli/vitest.config.ts` (new) **CI:** - `.github/workflows/qemu-emulator-build.yaml` ## Test plan - [x] `docker/local-emulator/qemu/build-image.sh {amd64,arm64}` produces `stack-emulator-<arch>.qcow2` with snapshot-compatible topology - [x] `stack emulator pull` downloads qcow2 with progress, then captures locally (~1–3 min) and writes `stack-emulator-<arch>.savevm.zst` in the images dir - [x] `stack emulator pull --skip-snapshot` stops after download - [x] `stack emulator pull --pr <n>` / `--run <id>` pull from PR / workflow run artifacts - [x] `stack emulator start` on a fresh dir auto-pulls **and** auto-captures, then starts; subsequent starts fast-resume in ~5–8s; backend + dashboard return 200 - [x] `EMULATOR_NO_ROTATION=1 stack emulator start` completes in ~2.5s; backend + dashboard return 200 with warning printed - [x] Two consecutive `emulator start` invocations produce different PCK values in the internal `ApiKeySet` row - [x] `stack emulator status` / `stop` / `reset` resolve paths from `STACK_EMULATOR_HOME` - [x] Verified end-to-end on arm64 macOS under HVF (capture ~50s, fast-resume ~6.5s) - [x] `pnpm lint` and `pnpm typecheck` pass; stack-cli unit tests (iso + emulator) pass - [ ] CI green on this PR (qemu-emulator-build matrix, smoke test) - [ ] `gh release download emulator-<branch>-latest` contains only `stack-emulator-<arch>.qcow2` once this PR merges and publish runs <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Snapshot fast-start/resume with optional warm-snapshot assets, runtime ISO generation, and a cached QEMU build to speed emulator setup. * CLI: streamed artifact downloads with progress, improved release/asset handling, stronger preflight checks, and start/status/stop emulator commands. * Automated secret rotation and ability to apply rotated secrets at container startup; supervisor control socket enabled. * **Bug Fixes** * More robust start/stop/resume flows with automatic fallback to cold boot and improved process-group shutdown behavior. * **Tests** * New tests for CLI utilities and ISO image generation. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-04-20 14:24:49 -07:00
BilalG1	0621ad2032	ai proxy fix (#1343) ... <!-- Make sure you've read the CONTRIBUTING.md guidelines: https://github.com/stack-auth/stack-auth/blob/dev/CONTRIBUTING.md --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Request sanitization now includes an extra proxy-specific preprocessing step for safer AI proxying. * **New Features** * Initialization prompts centralized into a shared helper, with a web-specific prompt variant. * Authenticated requests can optionally route via a provided external API key to access alternate models. * **Chores** * Added and exposed a preprocessing hook with a default no-op implementation. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-04-19 22:57:38 -07:00
Armaan Jain	654c97c56e	Onboarding redo (#1308)	2026-04-15 09:35:48 -07:00
Mantra	7f8e3df852	feat: add anonRefreshToken to CLI auth flow and enhance session management (#1303) ... - Extended `CliAuthAttempt` with `anonRefreshToken` and a migration. - CLI `POST /auth/cli` accepts optional `anon_refresh_token` (must be an anonymous user's refresh token for the current project). - `POST /auth/cli/complete` supports `mode` `check` (anonymous vs none), `claim-anon-session` (issue tokens for the linked anonymous session), and `complete` (bind the browser session's refresh token to the attempt). Completing clears `anonRefreshToken` on the row. We do **not** merge anonymous account data into the signed-in user (that behavior was removed as a security risk; the anonymous user remains unchanged). - Template CLI confirmation page, stack-cli optional `STACK_CLI_ANON_REFRESH_TOKEN`, SDK/spec updates, and e2e coverage. <!-- Make sure you've read the CONTRIBUTING.md guidelines: https://github.com/stack-auth/stack-auth/blob/dev/CONTRIBUTING.md --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * CLI login supports attaching anonymous sessions and a multi-mode confirm/claim/check flow; CLI tools now surface login codes and remove anon token after use. * Added interactive CLI auth demo page and a CLI simulator script. * Client libraries: prompt flow accepts an optional anon token and a promptLink(url, loginCode) callback. * **Tests** * Expanded end-to-end coverage for anonymous CLI sessions, claim/complete/poll flows, upgrades, and error cases. * **Documentation** * Updated prompt CLI docs/spec to describe new options and callback signature. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-04-14 02:09:35 +00:00
Mantra	3efb226c59	make publishable client keys truly optional ig (i hope) (#1274) ... <!-- Make sure you've read the CONTRIBUTING.md guidelines: https://github.com/stack-auth/stack-auth/blob/dev/CONTRIBUTING.md --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Documentation * Updated setup instructions across all documentation to clarify that the publishable client key is only required when your project configuration enforces it, removing confusion about unconditional requirements. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-03-23 15:09:01 -07:00
Bilal Godil	35b7e72ff2	prompt fix	2026-03-13 13:20:25 -07:00
BilalG1	3c6372a971	stack cli fixes (#1252) ... <!-- Make sure you've read the CONTRIBUTING.md guidelines: https://github.com/stack-auth/stack-auth/blob/dev/CONTRIBUTING.md --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Fixed authentication errors in the Claude agent. * **Refactor** * Simplified the CLI initialization process to default to cloud project linking, removing interactive prompts. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-03-13 13:07:13 -07:00
BilalG1	f016cd8993	CLI init (#1242) ... <!-- Make sure you've read the CONTRIBUTING.md guidelines: https://github.com/stack-auth/stack-auth/blob/dev/CONTRIBUTING.md --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Interactive init workflow (create, link-config, link-cloud) with safe non-interactive behavior; writes/updates project config and .env, and prints STACK AUTH setup instructions. * CLI assistant/agent with a progress UI for long-running tasks. * Backend AI proxy endpoint that validates and forwards AI requests to an external provider. * **Tests** * End-to-end tests covering all init modes, outputs, env linking, and error cases. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-03-13 10:55:22 -07:00
BilalG1	57149bd84b	Stack CLI (#1227) ... <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **New Features** * Added Stack CLI with authentication (login/logout) commands. * Added project management commands to list and create projects. * Added configuration management to pull and push project settings. * Added code execution capability to run JavaScript expressions. * Added initialization command for Stack Auth setup. * **Tests** * Added comprehensive end-to-end test suite for CLI functionality. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-03-09 13:24:15 -07:00