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:

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.