Repository navigation
bug(runtime-host): interactive turns omit sandbox context and can loop on workspace-local Bash #3445
Description
What happened
In an Auto session with a selected local Git workspace, Maka could inspect and correctly edit a small project, but it could not run purely local validation.
Both GPT-5.3 Codex Spark and GPT-5.6 Sol requested unnecessary or invalid sandbox expansions for workspace-local Bash commands. The observed declarations included:
- a relative
"."path; scope: "exact"for a directory;network.enabled: truefor commands such asls -laand localnpm test.
The Runtime correctly failed closed, but the Agent then alternated between Bash and request_sandbox_boundary, changing the arguments slightly and repeatedly requesting equivalent or broader authority. In the Spark run, this produced roughly 28 Bash/boundary attempts before I stopped the turn. Maka never ran the tests or produced a completion response.
The code change itself was correct. Running npm test outside Maka immediately passed all three tests.
Expected behavior: ordinary workspace-local, no-egress Bash commands should run inside the existing Auto boundary without requesting an expansion. If an expansion is genuinely required, the Agent should request the smallest valid authority and converge after approval or denial.
This blocks the production first-verified-result path described in #2469 Phase 1 and #2614.
How to reproduce
- Create a clean Git repository with no dependencies:
package.json:
{
"name": "maka-product-lab",
"private": true,
"type": "module",
"scripts": {
"test": "node --test"
}
}src/order-total.js:
export function calculateOrderTotal(items, discountPercent = 0) {
const subtotal = items.reduce((total, item) => total + item.price, 0);
return Math.round(subtotal * (1 - discountPercent / 100) * 100) / 100;
}Add three node:test cases covering a single item, multiple quantities, and a percentage discount. The baseline should be one passing and two failing tests.
- Start Maka Desktop from source.
- Select the repository as the project and keep Permissions on Auto.
- Submit:
Inspect this project, identify why the tests fail, fix the implementation bug, and run the relevant tests. Do not change the tests unless they are incorrect. When you finish, explain what changed and show the verification evidence.
- Observe the first workspace-local Bash calls and any resulting boundary requests.
- Reject an unnecessary network expansion if prompted.
Observed with GPT-5.3 Codex Spark:
{
"command": "ls -la",
"required_boundary": {
"filesystem": {
"entries": [
{
"path": ".",
"access": "read",
"scope": "exact"
}
]
},
"network": {
"enabled": true
}
}
}The first failures were:
Sandbox boundary path must be a normalized absolute path.
An exact sandbox boundary cannot target a directory; use subtree for directory access.
After correcting parts of the declaration, the Agent continued requesting network access for local-only work and did not complete validation.
Environment
- Maka commit:
e44ddcec5d8a94f3e584953947e707205971e774 - OS: macOS 27.0
- Surface: Desktop Dev / Runtime Host
- Node.js: v26.5.0
- Models reproduced:
- GPT-5.3 Codex Spark
- GPT-5.6 Sol
- Permission mode: Auto
- Fixture baseline: 1 passed, 2 failed
- Expected result after the implementation fix: 3 passed
Logs, screenshots, or additional context
Investigation suggests that the production Runtime Host no longer provides the model-visible sandbox diagnostics that existed before the M5 cutover:
- feat(runtime): expose active sandbox diagnostics #1278 and feat(runtime): implement Plan collaboration mode #1305 introduced a session-scoped
<sandbox_context>containing the effective filesystem policy, network policy, cwd, and sandbox capabilities. - feat(runtime-host): complete M5 production cutover #2420 removed the old Desktop/CLI composition paths.
AiSdkBackendstill supports injectingsandboxDiagnosticsSnapshot, but the current production Runtime Host composition does not appear to supply it.- The current Host turn tail contains environment, task ledger, and Plan information, but not the authoritative sandbox context.
- The captured provider request contained the informational
<env>fragment, which explicitly says it grants no authority, and no<sandbox_context>.
Relevant current source:
packages/runtime-host/src/server/interactive-run-composer.tspackages/runtime/src/ai-sdk-backend.tspackages/runtime/src/sandbox-boundary-declaration.tspackages/runtime/src/builtin-tools.ts
The Bash schema may compound the missing context: its nested filesystem fields do not tell the model that paths must be normalized absolute paths, directories require subtree, or that required_boundary should be omitted when the current boundary already covers the command.
Suggested regression coverage:
- derive model-visible sandbox context from the live
ExecutionBoundary.profile, not a potentially stale Session header mode; - exercise the production Runtime Host → ToolRuntime → Bash → sandbox path;
- verify that workspace-local
lsandnpm testrun without expansion; - verify that network is requested only for commands that genuinely require process egress;
- verify that invalid or denied equivalent expansions do not create an unbounded retry loop.
PR #2616 is related but does not cover this path: its FakeBackend directly writes the file, executes validation, and publishes synthetic Write/Bash events, bypassing the real model, ToolRuntime, Bash schema, boundary preflight, and sandbox manager.
Related:
- roadmap(product): evolve Maka into a durable Agent workspace #2469
- test(desktop): prove the first verified-result journey #2614 / test(desktop): prove first verified result journey #2616
- feat: replace per-tool approvals with sandbox boundaries #1564 / feat: replace tool permissions with session sandbox boundaries #1581
- feat(runtime): expose active sandbox diagnostics #1278 / feat(runtime): implement Plan collaboration mode #1305
- feat(runtime-host): complete M5 production cutover #2420
- macOS: Maka Desktop diagnostic report 反复中断工作 #3328
AI-assisted investigation disclosure: Codex helped run and compare the two-model reproduction, inspect the captured Runtime artifacts and repository history, search for related issues and pull requests, and draft this report. I reviewed the findings and own the submission.
Activity
yihanzhu commentedon Aug 22, 2026
I did some local A/B testing against the current
mainand found that this appears to involve two separate layers.<sandbox_context>improved the model's first path selection, but it still repeatedly supplied speculativerequired_boundaryvalues.boundary_intent: "current" | "expand"discriminator did: ordinary commands using"current"ran within the existing boundary without triggering expansion, while"expand"remained fail-closed and required an explicit boundary.That allowed the task to progress until
npm testexposed a separate macOS substrate issue: Seatbelt blocked Homebrew Node's dynamically linked libraries. A temporary broad Homebrew read grant made both tested models complete the full edit-and-verify journey, but that grant was intentionally reverted because it is too broad for a real fix.The local prototype for live per-turn diagnostics and the Bash intent discriminator currently passes:
git diff --check: passedI have not opened a PR because the safe Node runtime-dependency handling is a separate security-boundary decision. Would maintainers prefer #3445 to stay scoped to live sandbox context and explicit Bash boundary intent, with the macOS runtime dependency work tracked separately?
AI use disclosure: OpenAI Codex substantially assisted with the local analysis, A/B experiment design, prototype implementation, test execution, and drafting of this comment. I reviewed the evidence and take responsibility for the conclusions.
yihanzhu commentedon Aug 22, 2026
Thanks for triaging this. I'd like to work on it.