fix(daytona): bump @daytonaio/sdk, supplement sandboxClass/warmPoolId

[miyaontherelay]

Summary

Track 4 wire-supplement lane. Original charter (relayed via sandbox-lead-claude-0820b) claimed 5 Daytona wire fields (autoDestroyAt, autoPauseInterval, sandboxClass, spot, warmPoolId) were entirely missing from @daytona/api-client's SDK types. Independently re-verified against the real upstream (daytona/clients on GitHub, npm registry) before writing any code — that premise didn't hold:

• autoDestroyAt, autoPauseInterval, spot (+ spotEvictedAt) already ship on the public Sandbox class as of @daytonaio/sdk 0.200.0–0.205.0. Our repo was just pinned to 0.180.0 (2026-05-24), 25 minor versions / ~3 months stale against latest 0.205.1 (2026-08-20). A dependency bump alone covers these three.
• sandboxClass, warmPoolId are a real, narrower gap: present on the low-level @daytona/api-client DTOs, but sdk-typescript's processSandboxDto() never copies them onto the public Sandbox class — confirmed against daytona/clients HEAD today, not just our stale pin. This needs the small supplement below.

Filing the originally-briefed "5 fields missing" issue upstream would have misrepresented daytona/clients' own already-shipped work (#192 "feat: spot gpus" etc.) to a real maintainer. Revised scope signed off by sandbox-lead-claude-0820b before any code was written.

Changes

• package.json: bump @daytonaio/sdk peer/dev dependency from >=0.180.0 <0.181.0 / ^0.180.0 to >=0.205.0 <0.206.0 / ^0.205.1.
• src/daytona/wire-supplement.ts (new): fetchDaytonaWireSupplement() fetches sandboxClass + warmPoolId via the low-level sandboxApi.getSandbox() — the same reach pattern runtime.ts already uses for detached create — since the SDK's Sandbox class drops both.
• src/daytona/runtime.ts: exposes it as DaytonaRuntime.getWireSupplement(handle). Opt-in, not merged into the shared RuntimeHandle/WorkflowRuntime types — this is Daytona-specific, not something to generalize across providers.
• src/index.ts: barrel-exports fetchDaytonaWireSupplement / DaytonaWireSupplement.
• README.md: new "Daytona wire-supplement" section (matching the existing "E2B runtime contract" convention — this repo documents providers inline in the README, not a docs/ folder) explaining the gap, retirement path, and linking the upstream tracking issue.
• Tests (src/daytona/runtime.test.ts):
  • Two unit tests for getWireSupplement (present + absent field cases) against a faked sandboxApi.
  • A load-bearing regression test in the existing DAYTONA_API_KEY-gated smoke suite with a MUST-FIRE/MUST-NOT-FIRE pair: asserts the live wire response still carries sandboxClass (fails if Daytona drops it), and asserts the SDK's own Sandbox class still exposes autoDestroyAt/autoPauseInterval/spot (fails if a future SDK regresses those). warmPoolId isn't asserted live — it's only set for unclaimed warm-pool members, which the ordinary smoke sandbox isn't; asserting it would require standing up a warm-pool sandbox, out of scope here.

Breaking-change scan

Walked every daytona/clients PR merged since 0.180.0's publish date against every method this adapter calls: create/get/list/start/stop/delete, process.executeCommand/createSession/executeSessionCommand/getSession/getSessionCommand/getSessionCommandLogs, fs.uploadFile/downloadFile/getUserHomeDir. All confirmed unchanged by diffing the current sdk-typescript source directly, not just changelogs. The one PR touching error codes (#149) was TypeScript-SDK-only-already-had-it; the change propagated other-language SDKs, no TS impact. Full details in the commit message.

Verification

npm itself hangs indefinitely on this host (even npm --version, unrelated to this change — confirmed hanging in an empty scratch dir too, and multiple other agents' pnpm/npm processes on this machine are also stuck; looks like host-level resource contention across the fleet, not this change). Worked around it: manually staged the real published @daytonaio/sdk@0.205.1 + @daytona/api-client@0.205.1 (+ transitive deps) into node_modules via direct registry curl (registry access works fine, only the npm binary itself hangs), then ran the compiler/test runner directly:

• node node_modules/typescript/bin/tsc -p tsconfig.json --noEmit — clean, zero errors, full src/ tree, strict mode.
• node --import tsx --test "src/**/*.test.ts" — 201 pass, 0 fail, 4 skipped (the DAYTONA_API_KEY/other-provider-key-gated smoke tests — no live credential available yet).

Please still run npm ci && npm test in CI/your own environment before merge as a sanity check — I could not use the repo's own tooling to verify this, only a manual dependency-staging workaround.

Upstream

Filed against daytona/clients (the real repo — daytonaio/api-client as originally briefed doesn't exist): daytona/clients#207

Out of scope (left alone)

• daytona-lifecycle-fix-0820's exec-dead-after-restart bug (lane/daytona-lifecycle-fix-0820, PR fix(daytona): recover exec after sandbox restart #14) — untouched.
• sandbox#10 Micro destroy leak fix, sandbox#11 Agent37 rebase — untouched.
• Generalizing this supplement pattern to other providers (Vercel/Modal/E2B/Freestyle/Microsandbox) — noted as a possible follow-up finding, not this lane's scope.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: d303edcb-28a8-430d-87a5-9414403e8b23

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[miyaontherelay]

CI status note: npm ci will fail right now — package-lock.json wasn't regenerated because npm/pnpm/yarn/corepack all hang indefinitely on this host (Finn-Mac-Mini). Root cause looks like fleet-wide resource contention, not this change: ps aux shows 92 npm/pnpm processes currently running here, several stuck since last week. Tried two separate Node installs (25.8.1 and 22.22.1) — both hang.

The code itself is verified independent of the lockfile: I manually staged the real published @daytonaio/sdk@0.205.1 + @daytona/api-client@0.205.1 into node_modules via direct registry curl (registry access is fine — only the npm binary itself is stuck) and ran the compiler/test runner directly:

• node node_modules/typescript/bin/tsc -p tsconfig.json --noEmit — clean, 0 errors
• node --import tsx --test "src/**/*.test.ts" — 201 pass, 0 fail, 4 skipped

package-lock.json still needs a real npm install on a healthy host before this is mergeable. Flagged to sandbox-lead-claude-0820b for a working node to run it on — will push the regenerated lockfile as a follow-up commit once that's unblocked.

[cubic-dev-ai]

All reported issues were addressed

_{You’re at about 94% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.}

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[kjgbot]

Status update — worker on agent/daytona-wire-supplement-0821

Threads resolved: 1 (cubic-dev-ai on src/daytona/runtime.test.ts — regression test now has a MUST-FIRE retirement signal for sandboxClass/warmPoolId landing on the SDK Sandbox class; see reply).
Threads remaining: 0.

Fix commit: f0b42b9abaf6219a (folded into the rebase resolution per the same-commit-landing rule — the review comment targeted the same file+block the rebase had to touch, so a follow-up commit would just add reviewer hops).

Rebase: main advanced with #14 (fix(daytona): recover exec after sandbox restart) and #17 (feat(port): structured capability modes) after this PR was originally opened, so the PR was DIRTY. Rebased onto origin/main (51d7ee9), resolved two conflicts in src/daytona/runtime.test.ts (dropped a duplicate let daytona from the smoke-suite state block; kept both #14's new must-fire: stop then start smoke and this PR's wire response still carries sandboxClass… regression as separate it(...) blocks). Force-pushed with --force-with-lease.

Verification (per-workflow, not the rollup):

• .github/workflows/ci.yml → run 32514741968 on head 80c0c3c → success (single job Build & Test: success).
• .github/workflows/publish.yml → does not run on PR events (tag/main only) — nothing to verify here.
• cubic · AI code reviewer app check on the new head reports neutral with output Automatic AI review not started after branch rewrite — its prior review against f8b3798 had already surfaced the one issue, which is now addressed and folded into f0b42b9.

Local npm run typecheck + full npm test after rebase: 220 tests, 215 pass / 5 skipped (live-Daytona-only).

mergeable=MERGEABLE, mergeStateStatus=CLEAN on head 80c0c3c. Merge-ready — leaving the merge gate to @khaliqgant.