Test It Locally

Test the changed behavior and its stored state, not just whether the app loads.

Workflow

1. Inspect the worktree stack. Read the whole plaintext output: it includes the local WorkOS organization, routes, ports, logs, generated env state, and an API health line. Sync only if it is missing or stale; --compose --seed is usually already done, then run status again.

bun --bun run devstack status
bun --bun run devstack sync --compose --seed

2. Use the API healthcheck line from the full bun --bun run devstack status output. passed means the app stack is ready; failed means it is not running.

3. If it failed, start Riptide in a tmux session that excludes the parent daemon's identity. This keeps the initial process and any later panes on the devstack's local identity. Use riptide:native only when the native shell matters.

STACK_ID="$(bun --bun run devstack status --json | jq -r '.id')" && \
TMUX_SESSION="riptide-$STACK_ID" && \
tmux new-session -d -s "$TMUX_SESSION" -c "$PWD" \
  "env -u DAEMON_IDENTITY -u RIPTIDE_DAEMON_EXPECTED_IDENTITY bun --bun run riptide" && \
tmux set-environment -u -t "$TMUX_SESSION" DAEMON_IDENTITY && \
tmux set-environment -u -t "$TMUX_SESSION" RIPTIDE_DAEMON_EXPECTED_IDENTITY
tmux attach -t "$TMUX_SESSION"

Do not use tmux set-environment -gu; the tmux server is shared by other devstacks.

4. Open the worktree URL headless with a browser session and profile keyed by the devstack ID. The named session isolates the running agent-browser daemon, while the profile persists cookies, IndexedDB, and cache. Both are needed so multiple devstacks can run browser checks in parallel without sharing state. Do not use --session-name, the fixed riptide profile, or a fixed localhost port.