feat: add TrueFoundry shared Daytona sandbox

[sr07asthana]

Summary

Closes #

Changes

How was this tested?

Checklist

• I have read the contributing guidelines
• pnpm build, pnpm test, pnpm typecheck, pnpm lint:ci, and pnpm format:check pass locally
• Tests added/updated where it makes sense
• No hand-edits to generated code (packages/trueforge-sdk, .github/fern/openapi/openapi.json, docs/openapi.json) — fork PRs omit SDK regen; maintainers regenerate after merge
• Docs / .env.example updated if configuration or behavior changed

---

Note

Medium Risk
Changes the sandbox resolution path for all tenants in TrueFoundry mode and depends on a shared API key plus an authenticated settings endpoint; misconfiguration or settings-server outages affect skills/sandbox turns broadly.

Overview
TrueFoundry mode can now use a shared Daytona sandbox for every tenant when SANDBOX_ENABLED=true, wired through SANDBOX_API_KEY and SANDBOX_SETTINGS_SERVER_URL. Snapshot name and lifecycle knobs come from the settings server (Bearer token per request), not from per-tenant PUT /api/v1/settings/sandbox-providers; those writes still hit the DB in self-serve mode but in TF mode the new store rejects mutations with 424 (managed by TrueFoundry).

Sandbox provider access is refactored from a singleton sandboxProviderStore to resolveSandboxProviderStore(c), matching models/MCP/agents: in TrueFoundry mode each HTTP request gets TrueFoundrySandboxProviderStore (synthetic ready record with build_ref = snapshot name, 5‑minute settings cache); without request context (scheduler) the persistence store is used. Startup fails fast if TF mode has SANDBOX_ENABLED without API key + settings URL.

Docs/changeset and unit tests cover the new store (cache, timeouts, managed responses).

^{Reviewed by Cursor Bugbot for commit 1a85568. Bugbot is set up for automated code reviews on this repo. Configure here.}

[changeset-bot]

🦋 Changeset detected

Latest commit: 1a85568

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@truefoundry/trueforge	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[cursor]

Schedules miss shared Daytona store

Medium Severity

In-process schedule turns resolve the sandbox store with no request context, so TrueFoundry mode falls back to the empty SQL store. Shared Daytona from SANDBOX_ENABLED is invisible there, and sandbox-enabled scheduled runs fail as unconfigured even though interactive turns work.

Additional Locations (1)

• packages/trueforge/src/main.ts#L230-L237

 

^{Reviewed by Cursor Bugbot for commit 3d2325f. Configure here.}

[sr07asthana]

@heerambavi1998 should we add fallback to static settings json in this case?

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 1a85568. Configure here.}

[cursor]

Scheduler misses shared Daytona sandbox

Medium Severity

In TrueFoundry mode, resolveSandboxProviderStore() without a request context returns the SQL persistenceStore instead of TrueFoundrySandboxProviderStore. Schedule turnDeps resolve that way at startup, so cron and manual run-now never load the shared Daytona config from SANDBOX_API_KEY and the settings server. Those runs then see no provider, or a leftover per-tenant row, while interactive turns use the shared sandbox.

Additional Locations (1)

• packages/trueforge/src/app.ts#L333-L334

 

^{Reviewed by Cursor Bugbot for commit 1a85568. Configure here.}