## Approval is not a sandbox Boundary Desk ends by separating two claims that often get compressed into one\: “the application admitted the call” and “the environment allowed the effect\.” Approval is an application\-level decision\. It neither changes the process’s OS authority nor certifies every action the implementation may perform\. A successful call can still have effects outside the boundary its name suggests\, and an approved call can still fail later\. ### Provider safety is an independent required decision Inspect `boundary-provider-check-no-ui`\. It combines a read declaration\, yolo\, `autoApprove: true`\, user allow\, no UI\, and synthetic pending computer safety metadata\. **Prediction\:** does any of that automatic approval acknowledge the pending safety check\? **Recorded answer\:** no\. The wrapper emitted an approval lifecycle pair ending false\, executed nothing\, and reported that pending provider safety checks had no interactive UI\. `providerSafetyApproved` remained false\. In `boundary-provider-check-approved`\, the recording adapter selected Approve\. The prompt included `Fictional seed shelf check`\; the context flag became true and the inert executor recorded one call\. The source makes pending checks independently require approval\, regardless of yolo\, ordinary user allow\, or forwarded xdev admission\. It obtains computer actions and pending checks from provider metadata\, not by treating arbitrary prose as a safety grant\. The proof here is deliberately narrow\: synthetic metadata passed through the actual wrapper\. No provider delivered a request\, no screenshot was taken\, and no desktop input occurred\. This local acknowledgement mechanism is also not the entirety of a provider’s safety policy or refusal behavior\. ### An OS error arrives at another seam Now inspect `boundary-fallback-no-handler`\. The actual `writeFileWithFallback()` helper received an injected BunFile\-shaped primitive whose `write()` throws a synthetic `EACCES` error\. No fallback handler was registered\. **Recorded answer\:** one primitive attempt\, zero successful effects\, and the identical error object rethrown\. There was no privileged channel and no recovered write\. Compare the two error\-classification cases\: | Case | Error data | Recorded classification | | --- | ---: | --- | | `boundary-fallback-code-precedence` | Structured code `ENOENT`\; message mentions a path containing `EACCES` | Not permission\-denied\. | | `boundary-fallback-message` | No structured code\; Error message contains `EACCES` | Permission\-denied\. | `isPermissionDeniedError()` treats a structured code as authoritative\. Only when that structured information is absent does its message fallback apply\. A word in a pathname is not an OS denial\, and a classified denial is not an acquired grant\. ### What a file fallback contract actually provides The source supports a later host seam for selected native ordinary\-file byte writes and unlinks after permission errors\. Direct `EPERM`\, `EACCES`\, and `EROFS` can qualify\. A registered write fallback also enables a special check for a denied parent\-directory creation that Bun initially presents as `ENOENT`\; an ordinary missing or invalid path is not automatically a permission boundary\. The destination is resolved according to the primitive’s semantics\. Writes follow the final symlink target\; unlinks leave the final link itself as the object to remove\. An unverifiable write destination is not handed to a handler\. Delete handlers use a separate registry\, and `confirmedFile: false` does not authorize recursive removal\. Those registries are process\-wide\. A request’s origin session can differ from the session that registered a handler and owns its UI\. Returning true tells native code to proceed as though the supported primitive succeeded\; it is not itself proof that bytes became durable\. These are host contracts to understand\, **not a broker exercise for this route**\. The existing [Permission\-denied file fallbacks]() chapter retains the complete adapter and its missing real\-broker prerequisites\. No elevated writer is supplied here\. ### Several effects remain outside this particular seam A native byte\-write fallback is not exhaustive syscall interception\. It does not universally cover arbitrary extension filesystem calls\, shell or subprocess writes\, archive\-member rewrites\, SQLite row operations\, ACP client\-side writes\, independent LSP workspace edits\, or formatter subprocess mutations\. Similarly\, the approval wrapper is not a restriction on arbitrary imported JavaScript\. The supplied `isProjectTrusted()` compatibility method returns true\; it does not establish a per\-directory consent prompt or OS sandbox\. Tool selection\, approval\, and trust in loaded code must remain separate subjects\. Canonical path handling reduces particular misrouting risks\. Do not promote it into a general claim that every race\, host process\, network route\, or external side effect is constrained by the same policy\. The private verifier’s launcher used a clean environment and an OS sandbox with named restrictions\. Those restrictions describe that evidence\-producing child\, not an OMP feature installed for the reader and not a full sandbox validation suite\. Its effect counters cover instrumented seams\, not every possible effect of arbitrary imports\. **Paper checkpoint\:** can Approve repair `EACCES`\, and does a fallback returning true independently prove durable bytes\? **Worked answer\:** neither\. Approval admits an application call\. The OS\/host still governs the primitive\; a handler’s success is a contract that a real implementation must satisfy and verify\. **Failure boundary\:** the private fallback case was injected\, while the existing focused tests include local kernel\-permission fixtures and stand\-ins\. Neither establishes a real privileged broker or blanket OS isolation\. **Source anchors\:** `packages/coding-agent/src/extensibility/extensions/wrapper.ts` — `computerSafetyChecks`\, `approvalArgs`\, `ExtensionToolWrapper.execute`\; `packages/coding-agent/src/tools/file-write-fallback.ts` — `isPermissionDeniedError`\, `writeFileWithFallback`\, `deleteFileWithFallback`\, `withFileMutationSession`\; `packages/coding-agent/src/tools/path-utils.ts` — `resolveSyscallTarget`\; `packages/coding-agent/src/extensibility/extensions/runner.ts` — `createContext`\, fallback initialization\/disposal\.