This page covers repositories on the classic setup
script. Repositories with committed
.niteshift/
configuration declare auth in the service manifest: see Browser
authentication.- No auth: previews show the unauthenticated view. No credentials are stored or injected.
- Use static cookies across all tasks: record a session once (or paste cookies in by hand) and Niteshift injects them into every task’s browser and preview links. Best for hosted auth providers (AuthKit, Clerk, Okta) and persistent backing services (Neon, Supabase).
- Per-task login: your setup script writes cookies to
/tmp/agent-browser-state.json, and Niteshift syncs that file to the agent’s browser on launch and to preview links so you see the same authenticated session the agent does. Best for per-task seeded users or short-lived sessions. Use Edit with agent to have the setup agent draft the seeding code for you. - Manual login (username & password): add custom instructions
with test credentials (e.g.
user@example.com/test123) and the login flow. The agent drives the login itself each task, and you can also log in manually on previews.
Recording a session
Select Use static cookies across all tasks, click Save, then click Record session. From there the flow is the same as for.niteshift/ repositories:
a short-lived task boots an environment and opens the browser at your app, you take over via
Control Browser and log in, and Save stores the encrypted session scoped to the repository
and your user.
Debugging login issues
Login failures share the same causes and fixes as.niteshift/ repositories. The cookie strategies (Use static cookies across all tasks and
Per-task login) plant cookies before loading your application, so hosted sign-in pages that
refuse to render in an iframe never trigger; with No auth, apps that redirect to a login on
mount will fail to load in the preview.