Merge request: OD sandbox runtime PR stack (#3242-#3246)

[dredozubov]

Context

The OD sandbox runtime work is split into five small PRs so each review stays focused, but the PRs are intentionally stacked and are costly to keep rebased as main moves.

As of this check, all five PRs are open, non-draft, mergeable, approved, and have no pending or failing checks:

1. feat(daemon): add sandbox runtime foundation #3242 - feat(daemon): add sandbox runtime foundation
2. fix(daemon): confine sandbox project roots and host discovery #3243 - fix(daemon): confine sandbox project roots and host discovery
3. feat(daemon): add run-scoped MCP tool bundles #3244 - feat(daemon): add run-scoped MCP tool bundles
4. feat(daemon): add project export manifest #3245 - feat(daemon): add project export manifest
5. feat(daemon): add contained project preview URLs #3246 - feat(daemon): add contained project preview URLs

Suggested Merge Order

Please merge them in this order:

1. feat(daemon): add sandbox runtime foundation #3242 first, because it establishes the run-scoped sandbox/runtime data root and headless runtime foundation.
2. fix(daemon): confine sandbox project roots and host discovery #3243 second, because it tightens project-root confinement and host-discovery behavior on top of the foundation.
3. feat(daemon): add run-scoped MCP tool bundles #3244 third, because run-scoped MCP/tool bundles depend on the sandbox/root invariants being in place.
4. feat(daemon): add project export manifest #3245 fourth, because the export manifest should land after the scoped runtime and project-root semantics are settled.
5. feat(daemon): add contained project preview URLs #3246 last, because preview containment builds on the same scoped project/artifact/runtime model.

If later PRs appear to include commits from earlier PRs, that is expected for the stack until the lower PRs merge.

Request

Could a maintainer take a pass through this stack and merge it in order when feasible? A timely merge would reduce repeated rebase/conflict churn and keep the reviewed sandbox-runtime work from drifting while main continues to move.

[lefarcen]

Hey @dredozubov! The layered breakdown here is solid — the dependency chain reasoning (foundation → project-root confinement → scoped tool bundles → export manifest → preview containment) makes the intended order genuinely easy to follow.

Verified the current state on all five:

PR	Title	State
#3242	feat(daemon): add sandbox runtime foundation	✅ APPROVED, MERGEABLE
#3243	fix(daemon): confine sandbox project roots and host discovery	✅ APPROVED, MERGEABLE
#3244	feat(daemon): add run-scoped MCP tool bundles	✅ APPROVED, MERGEABLE
#3245	feat(daemon): add project export manifest	✅ APPROVED, MERGEABLE
#3246	feat(daemon): add contained project preview URLs	✅ APPROVED, MERGEABLE

Routing this to the maintainer team now. Tagged with area/runtime to help visibility. One thing worth watching: as each PR in the stack lands, the remaining ones may need a quick rebase — just let us know if any drop out of the mergeable state in the meantime and we can help coordinate.

The stacked-PR approach with focused per-slice reviews is exactly the right way to get daemon-layer work like this through. Appreciate the patience while we sequence the merges. ❤️

[dredozubov]

@pftom @mrcfps @nettee, sorry to bother, but I'd like your input on this if possible

[mrcfps]

Hi @dredozubov — thanks so much for the careful breakdown and for taking the time to stack these PRs in a reviewable order. That kind of effort really doesn't go unnoticed, and we genuinely appreciate the contribution. ❤️

Just a quick note: this proposal and the associated PRs (#3242–#3246) are currently under internal review on our side. We're working through it and will get back to you as soon as possible. Thanks for your patience while we sequence the merges — we'll keep you posted here.

[dredozubov]

@mrcfps Thanks for getting back to me. I completely understand it's a design proposal first and code changes second. I personally think it'll allow the project to be orchestrated in new, exciting ways, which is a big enabler for everyone since it allows you to leverage what you did here. I'll be glad to provide info and insights on both design and this direction.

[mrcfps]

@dredozubov — quick update from our side: the team has reviewed the proposal and we're aligned on the sandbox-runtime direction. Thanks for structuring this as a layered stack; it made the trade-offs much easier to reason about, and we'd like to see it land.

Status on the stack:

• feat(daemon): add sandbox runtime foundation #3242 feat(daemon): add sandbox runtime foundation — ✅ merged. The scoped OD_DATA_DIR root and /api/ready readiness probe are now on main.
• fix(daemon): confine sandbox project roots and host discovery #3243 fix(daemon): confine sandbox project roots and host discovery — open, approved, mergeable.
• feat(daemon): add run-scoped MCP tool bundles #3244 feat(daemon): add run-scoped MCP tool bundles — open, approved, mergeable.
• feat(daemon): add project export manifest #3245 feat(daemon): add project export manifest — open, approved, mergeable.
• feat(daemon): add contained project preview URLs #3246 feat(daemon): add contained project preview URLs — open, approved, mergeable.

We'll merge the remaining four in dependency order (#3243 → #3244 → #3245 → #3246) as each one clears its final checks. Since #3242 just landed, the next ones in the chain may need a light rebase against main — feel free to refresh them at your convenience, or ping us here if you'd prefer we coordinate a rebase on your behalf.

A couple of notes so nothing gets lost between slices:

1. CI signal — please make sure pnpm guard + pnpm typecheck + the daemon vitest suite stay green on each PR after rebase; that's our merge gate for daemon-layer changes.
2. Contract surface — feat(daemon): add project export manifest #3245's export manifest and feat(daemon): add contained project preview URLs #3246's preview URLs both touch /api/* shapes. If anything in those evolves during rebase, please mirror it in packages/contracts in the same PR so web/daemon stay in lockstep.
3. Follow-ups — anything you discovered while stacking these (test gaps, doc updates, sandbox-mode UX) is welcome as separate issues; we'd rather keep this stack tight and ship incrementals after.

Really appreciate the patience and the quality of the breakdown. Excited to get the rest landed. ❤️

[lefarcen]

Thanks for the clear status update, @mrcfps. @dredozubov, using this thread as the coordination point for the remaining stack makes sense.

If rebasing #3243-#3246 on top of main changes any /api/* contract edge or trips the pnpm guard / pnpm typecheck / daemon vitest gate, please drop the affected PR number here and we can review that slice in context without losing the merge order.

[dredozubov]

#3244, #3245, #3246 are green and good to go. LGTM

[lefarcen]

Triage update:

• Classified as kind/feature, area/runtime, and triaged.
• feat(daemon): add sandbox runtime foundation #3242 and fix(daemon): confine sandbox project roots and host discovery #3243 are now merged.
• feat(daemon): add run-scoped MCP tool bundles #3244, feat(daemon): add project export manifest #3245, and feat(daemon): add contained project preview URLs #3246 are still open, approved, mergeable, and have green checks.
• Recommended next action is maintainer merge in the remaining dependency order: feat(daemon): add run-scoped MCP tool bundles #3244 -> feat(daemon): add project export manifest #3245 -> feat(daemon): add contained project preview URLs #3246.
• Keep this issue open until the remaining stack lands, then close as completed.

[dredozubov]

#3244 merged, #3245, #3246 green and ready to go

[dredozubov]

#3246 is the last one. Green and good to go.

[mrcfps]

Hey @dredozubov! 🎉 Happy to share that all the PRs in this stack (#3242–#3246) have been merged and landed on main. They'll be present in later releases.

Thanks again for the thoughtful work on this — really appreciate the care that went into the OD sandbox runtime stack. Looking forward to your next brilliant ideas! 🚀