fix(sandbox): apply upload permissions via Daytona

[iamjr15]

Summary

• replace shell-visible chmod/touch retries with Daytona's native filesystem permissions API for uploaded project files and the runtime manifest
• preserve immutable user-facing upload metadata while tracking each workspace materialization separately in Durable Object storage
• assign the sandbox runtime user and read-only modes after every upload or R2 repair, and make a failed protection step fail the operation instead of silently warning
• remove two stale internal type exports surfaced by the affected-workspace dead-code gate

Why

Toolbox uploads on the persistent Daytona volume can be owned outside the sandbox process namespace, so shell chmod commands cannot reliably see or protect them. The provider's file-permissions endpoint is the correct ownership boundary. Keeping its modified timestamp in a separate projection record also prevents repeated repairs without changing the upload timestamp users see.

Verification

• pnpm turbo lint typecheck build — 76/76 tasks passed on Node 24.18.0
• affected architecture boundary check — passed, 113 modules / 210 dependencies
• affected Knip workspaces — passed
• git diff --check — passed
• exactly one Drizzle migration remains: packages/db/drizzle/0000_current_schema.sql
• no database schema or migration changes

Production acceptance after merge

The live check will delete only the disposable workspace cache, confirm R2 restores the exact file before agent access, inspect owner/mode for both the upload and runtime manifest, and verify a following run does not rematerialize an unchanged file.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
cheatcode	Skipped		Jul 27, 2026 3:27pm