NightjarPilot limits and reliability
Nightjar is a single-host private pilot for trusted work using your connected Codex or Claude account. Start with disposable work and review the result. This contract describes deployed capabilities; local experiments and unreleased branches can differ.
Worker trust boundary
Runs on one worker share a Linux user, filesystem access, and native Codex/Claude login material. Independent conversations have separate working directories, but the native agents have full VM permissions. A hostile run can read another run’s files and credentials. Two concurrent runs do not have independent security sandboxes; sequential runs can also leave files or processes behind.
Google and other connector OAuth credentials stay encrypted on the Nightjar server. The worker receives a run-scoped gateway token for selected connections. A peer with full access to that worker can potentially read that token too. Connection selection, Only me sharing, and separate directories enforce application permissions, not isolation from hostile code on the same worker.
Use a worker for one trusted owner and workload boundary. Do not mix untrusted repositories or instructions with sensitive mail, calendar, or Drive work. Separate environments only provide a machine boundary when they actually use separate VMs; aliases for the same box do not. Stronger isolation is required before treating the pilot as a service for mutually untrusted users.
Google connections
Signing into Nightjar with Google and granting Calendar, Gmail, or Drive access are separate OAuth flows. A successful Google login does not prove a service connection works. In Connections, open the relevant account and select Check connection. A successful check verifies a small read, not writes or every possible operation.
As of September 15, 2026, Calendar, Gmail, and Drive connections on the hosted pilot passed real Google API checks. Gmail and Drive were newly authorized with explicit owner approval, read-only access, and Only me sharing. Their authorization still displayed Google’s unverified app warning. These checks verify Calendar listing, the Gmail profile, and a bounded Drive file listing; they do not establish broader provider approval or verify writes.
If Google shows an unverified-app warning, the operator must complete the applicable Google verification before offering frictionless public onboarding. Do not interpret this as a password problem or keep reconnecting an already working Calendar account. Granting restricted Drive or Gmail scopes is a separate, informed decision by the account owner. Google documents the warning and verification requirements.
For other failures:
| Symptom | Next step |
|---|---|
redirect_uri_mismatch before returning to Nightjar | Operator: register the production origin plus the exact callback /api/connections/oauth/google_calendar/callback, /api/connections/oauth/gmail/callback, or /api/connections/oauth/google_drive/callback on the connection OAuth client. |
disallowed_useragent in an embedded browser | Open Nightjar in your normal Chrome or Safari browser, sign in there, and start a fresh connection. Do not copy the temporary authorization URL between browsers. |
| Google says access is blocked or requires administrator approval | Inspect Google’s error and the account’s Workspace policy. Nightjar cannot override that policy. |
| Authorization link expired or already used | Start again from Connections in the same signed-in browser. Authorization state lasts 15 minutes and is single-use. |
| Nightjar’s app credentials were rejected | Operator: repair the client ID/secret pairing, then check the connection. Saved consent is retained. |
| Authorization expired or revoked | Reconnect that existing connection. Nightjar discards a refresh token explicitly rejected as invalid_grant. |
| Temporary provider failure or rate limit | Retry Check connection later. Consent is retained; this does not restart a run. |
| Connected, but a service read is denied | Check enabled APIs and granted scopes. Reauthorize only if permissions need changing. |
Disconnecting a Google connection asks Google to revoke its authorization. Google can also invalidate this account’s other Calendar, Gmail, and Drive connections under the same Google project, including other Nightjar workspaces. Recheck them afterward; do not disconnect a working account merely as a troubleshooting experiment. See Google’s revocation behavior.
Keep the provider’s error code, approximate time, and Nightjar run link for diagnosis; never share authorization URLs, tokens, or raw provider responses. Google can stop a flow before it reaches Nightjar, so missing server callback diagnostics do not establish success. The operator can inspect bounded connection diagnostics for seven days.
Capacity and deadlines
| Boundary | Current behavior |
|---|---|
| Control plane | One Node process with SQLite WAL on one persistent volume. No distributed control plane or high-availability failover. |
| Worker concurrency | Default one active run per physical worker. NIGHTJAR_CLOUD_CONCURRENCY=2 permits two independent cloud conversations with separate working directories. The hosted pilot was set to the default on September 15. Three or four are not supported by the deployed scheduler. |
| Exclusive work | Local and legacy shared-directory runs stay exclusive. The same conversation cannot run twice concurrently. Uncertain execution reserves its worker until reconciled. |
| Memory | Independent cloud runs have a 1,280 MiB process RSS guard and conservative build settings. This sampled guard is not an OS memory reservation or security boundary. |
| Pending work | At most 100 queued/running tasks per workspace. This is an admission limit, not a latency guarantee. |
| Execution timeout | 30–86,400 seconds; default 1,800 unless a saved agent overrides it. Queue waiting is outside this deadline. The worker requests cleanup at timeout; unreachable workers can take longer to confirm stopped. |
| Client waiting | MCP waits last at most 20 seconds per call. SDK/client wait timeouts and disconnection leave the remote run active. Cancel explicitly. |
| Incoming MCP | 120 requests/minute and eight in-flight requests per authenticated key/grant. HTTP 429 includes Retry-After: 5; repeated calls must still respect the minute budget. |
| JSON API | Default 300 requests/minute per API key. Failed bearer authentication is limited to 60/minute per address. These counters are in memory and reset on process restart; browser sign-in has separate controls. |
| Provider quotas | Google, native model subscriptions, and other services impose additional limits. Nightjar admission does not reserve provider capacity. |
These are pilot defaults and maximum supported settings, not throughput guarantees. Increased concurrency does not improve isolation. Inspect get_environment, queue explanations, and the Environment lease before submitting important work.
Retention and recovery
Runs, results, events, audit records, idempotency records, and worker project files have no automatic age-based deletion guarantee. Treat them as retained until an operator explicitly removes them; ask for deletion or export before relying on a retention deadline. Saved project ZIPs have a 25 MiB archive limit, 100 MiB expanded limit, and 250 MiB total archive budget; there is no automatic ZIP purge.
Database backups run after startup migrations and every 24 hours, retaining the latest seven completed backup days. They share the database volume. They help with application mistakes but cannot survive loss of that volume. Project ZIPs and worker-native credentials are excluded. Encrypted backup keys require the separately held backup passphrase; deployments without that setting copy key files in plaintext. The hosted pilot had encrypted backup keys enabled when inspected on September 15.
There is no off-site backup guarantee, stated recovery-time objective, or availability SLA. The nominal database backup interval is 24 hours; downtime or failures can make the latest usable backup older. The two databases have no cross-database transaction, so restoration requires an authorization and membership review.
After a restart, Nightjar polls known native invocations and reserves workers with uncertain execution. It does not automatically repeat a possibly started goal. Restored active tasks need inspection before retry; schedules pause on restore. An explicit follow-up starts new model work and can repeat external effects. Cancellation cannot undo completed writes or guarantee termination of hostile code with full VM permissions. Webhook delivery is at least once, with eight automatic attempts and manual retry; deduplicate by event ID.
Hosting lease
The hosted pilot is time- and budget-limited. On September 15, 2026, the operator renewed the existing service guard and the owner’s worker lease through September 22, 2026, at 18:00 UTC. This is a dated observation, not an automatic renewal promise. The configured hard stop, budget guard, and each Environment’s reported lease are authoritative; an earlier limit can stop service sooner.
Public static apps have a separate hosting lifecycle. A deployment marked live was verified at publication time; later pauses, budget enforcement, or expiry can make its URL unavailable without changing that historical result. Check the URL before sharing it. Export project files before a lease ends. The pilot supports ten apps per workspace, subject to a ten-app global allowance, and 25 MiB per deployment; server apps, databases, and app secrets are unsupported.
Suggested first tasks
Use MCP for 5–10 low-sensitivity tasks such as research on a test repository, a supplied-file report, or a disposable prototype. MCP makes submission and results convenient; it does not add a worker sandbox.
For each task, retain the run link, set a timeout, and send an idempotency key. Reuse the exact key and input after an uncertain submission. Idempotency is scoped to the workspace and submitting user; it deduplicates submission, not individual external writes or model behavior.
Begin with no saved agent and connectionIds: [], or explicitly select a read-only connection when needed. Review the output before granting write access for a later task. A prompt saying “ask before writing” is not a server-enforced per-write approval gate. A connection that allows writes can be used by the run without another human confirmation. No selected connection also does not remove the native agent’s shell or network access.
MCP’s Read only authorization lets the client inspect runs; it cannot start this experiment. Use delegation access to create runs, while keeping the selected service connections read-only.