Strix 1.4.1 + strix-sandbox:1.1.0 Caido bootstrap hangs on project.select — createProject returns null to guest tokens

[SaintGeele]

Bug: Strix 1.4.1 Caido bootstrap hangs on project.select(project.id) — createProject returns null to guest tokens in strix-sandbox:1.1.0

Environment

• strix-agent 1.4.1 (released 2026-07-27)
• strix-sandbox:1.1.0 (bundled in strix CLI on first run)
• caido-sdk-client 0.3.0 (resolved from >=0.2.0; verified 0.2.0 source is identical)
• Network mode: --network=host (because the new shared-network mode in v1.3.0 doesn't fit our VM resource model)
• Target: local directory

Symptom

Strix CLI completes login, launches the sandbox container, Caido HTTP endpoint responds on the host-mapped port (e.g. 127.0.0.1:32771), loginAsGuest GraphQL mutation succeeds with a valid access token, but project.create({ name: "sandbox", temporary: true }) then hangs the next call (project.select) until the SDK executes its 30s timeout. Wrapper exit:

caido_sdk_client.errors.graphql.OperationUserError:
  Source: TimeoutError on Caido project.select GraphQL call

Direct repro

With the sandbox running and a guest token in hand (curl-able from outside the sandbox on the host port mapping), the GraphQL createProject returns a null project:

PORT=$(docker ps --format '{{.Ports}}' | grep -oE '127.0.0.1:[0-9]+->48080' | head -1 | cut -d: -f2 | cut -d- -f1)
TOKEN=$(curl -sf -X POST http://127.0.0.1:$PORT/graphql \
  -H 'Content-Type: application/json' \
  -d '{"query":"mutation { loginAsGuest { token { accessToken } } }"}' \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['data']['loginAsGuest']['token']['accessToken'])")
echo "token=$TOKEN"  # works fine

curl -sf -X POST http://127.0.0.1:$PORT/graphql \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"query":"mutation { createProject(input: { name: \"smoke\", temporary: true }) { project { id name } } }"}'
# → {"data":{"createProject":{"project":null}}}

Same payload from a non-guest (admin-created) account presumably works — I haven't been able to test because Caido's auth model is closed-source and I can't create an admin without first getting past createProject.

What I've ruled out

• SDK bug? caido-sdk-client 0.2.0 and 0.3.0 source diff for project.create and project.select is identical (both raise MissingExpectedValueError on null payload). Updated SDK from latest pip resolves; downgrading to 0.2.0 wouldn't change behavior.
• Network/port resolution? In v1.3.0 strix added a shared-network port resolver that expects the sandbox on STRIX_DOCKER_SANDBOX_NETWORK. With --network=host, the parent's resolver fires and gets the host port mapping correctly. Sandbox container + Caido all reachable. Confirmed loginAsGuest works on that URL.
• Resource exhaustion? Increased --memory from 2g → 3g. No change in behavior.

My read of the cause

The Caido server shipped with strix-sandbox:1.1.0 returns null to a guest token's createProject. The closed-source Caido permission model apparently changed so guests have read-only project access but not create-project — and the strix SDK doesn't handle the null gracefully (it just calls select(project.id) on the resulting object, which then times out the GraphQL handshake).

Two reasonable fixes:

1. Caido docs / source change: re-grant create-project to guest tokens, OR ship a different bootstrap path in the sandbox that sets up an admin before project creation.
2. strix-side: check createProject.project for null and either (a) retry with a different token flow, (b) use an existing project from a list query, or (c) surface a clear error instead of timing out.

Workaround in the meantime

I've parked Strix and pivoted to semgrep + trivy fs (run from outside the container; trivy is the trivy AQUA scanner, not Caido). Real-world value caught in our first scan: 15 HIGH CVEs flagged on a Next.js project, 90 seconds, no LLM tokens. So we're not blocked. But the Strix path is the more interesting one for our use case (live HTTP exploit automation, browser-based XSS/CSRF checks) and would be useful to get back to.

Repo / commit references

• strix-agent 1.4.1: https://pypi.org/project/strix-agent/1.4.1/
• caido-sdk-client 0.3.0: https://pypi.org/project/caido-sdk-client/
• Caido repo (brand assets only): https://github.com/caido/caido

[SaintGeele]

30-second status (issue author): I have parked the Strix path pending Caido permissions clarification / SDK robust null-handling. Real-world pivot was trivy fs (AQUA scanner) plus semgrep --config p/security-audit — first pass on a Next.js 16.2.2 target surfaced 15 HIGH CVEs in 90s end-to-end, no LLM tokens, no Caido dependency. So we are not blocked.

The original bug report (above) has a stable repro recipe (curl-able from outside the sandbox on the host port, guest token succeeds loginAsGuest but createProject returns {data:{createProject:{project:null}}}). Happy to attach the full session log if useful, but the surface area is small enough to fix in either direction:

• Caido: grant createProject to guest tokens, OR ship a sandbox bootstrap path that creates an admin before project creation
• strix-sdk: guard for createProject.project == null, list existing projects, or surface a clearer error instead of the 30s select() timeout

Will leave this open until either side moves. Closing the duplicated "watch this" issue tracker references I had on internal kanban.

[FabioLeitao]

Root cause, confirmed against caido-cli 0.56.0/0.57.1: createProject returns a null project with a PermissionDeniedUserError in the error payload once the guest token's project cap (1 concurrent project) is hit — the SDK call that hangs (project.select) is hanging on a null id, not a real bootstrap issue. A sandbox that wasn't torn down cleanly (crash, force-kill) leaves a stale project occupying that single guest slot, and every subsequent run silently fails the same way.

Fix that's worked reliably for me: on createProject failure, list existing projects, and if one matches the name Strix uses ("sandbox") and is marked temporary, delete it and retry createProject — reclaims your own stale slot, refuses (without deleting) if the existing project isn't temporary/isn't ours. Patch against strix/runtime/caido_bootstrap.py if it'd help — can open a PR.

(Unrelated to the fix, but: this thread looks like it's gotten spammed pretty heavily — might be worth a mod pass.)