Repository navigation
Trusted tool result paths are unreadable through Developer's working-directory jail #437
Description
Describe the bug
A long-running connector job completed successfully and returned an absolute result-file path for downstream consumption. Reading that exact path with the built-in Developer text editor failed because the file was outside the session working directory. The only successful workaround was to copy the connector-owned result into the working directory with a shell command and then read the copy.
This breaks composition between tools: one trusted tool advertises a completed output path, while another built-in tool refuses that path.
To reproduce
- Start a connector job whose completed status returns a result path under the connector's managed application-data directory rather than the session working directory.
- Wait for the job to reach the completed state and obtain its returned result path.
- Call Developer text editor with command "view" and path set to that returned result path.
- Observe that the read is rejected as outside the working directory.
- Copy the same file into the session working directory with Developer shell, then read the copy successfully with text editor.
Expected behavior
A path explicitly returned by a trusted completed tool operation should be consumable by an appropriate downstream built-in tool without requiring a shell-copy workaround. Biorouter could authorize provenance-bound read access, stage results in a session-accessible artifact directory, or return an opaque result handle with a supported reader.
Suspected cause
High confidence. In Biorouter v1.93.2, DeveloperServer::resolve_path delegates every text-editor path to resolve_path_jailed; canonical paths not beneath the session working directory are rejected in crates/biorouter-mcp/src/developer/rmcp_developer.rs around lines 2075–2169. This check does not distinguish an arbitrary model-supplied path from a path issued by another trusted tool.
Biorouter's own docs/history/streaming-tool-call-ui-2026-07/tool-errors-audit.md classifies analogous outside-working-directory failures as defects. docs/history/agent-loop-review/subsystem-reviews/core-loop-and-tool-dispatch.md also notes the broader architectural contradiction: the harness can place tool output in a temporary or application-data location and tell the model to examine it even though file tools may be jailed away from that location.
The connector behaved consistently by returning its completed file, and the text editor behaved consistently with its jail; the missing piece is a provenance-aware cross-tool handoff. A safe fix would grant read-only access to exact paths emitted by trusted tool results, stage them automatically into a session artifact area, or replace raw paths with capability-scoped result handles.
Additional context
This report is intentionally limited to cross-tool file handoff and the path jail. It does not cover asynchronous job polling, capacity limits, or semantic failures encoded inside otherwise successful tool responses.
Do not attach a diagnostics bundle from the originating private chat to the public issue because it contains the conversation unredacted.
Verification status
Reported behavior is being checked against current source with synthetic reproductions. No originating private transcript or diagnostics bundle is attached. Related connector implementations: BaranziniLab/UCSFOMOPAgent and BaranziniLab/CDWAgent.
Activity
Broccolito commentedon Oct 24, 2026
The external-folder UX requirement is now consolidated in #424: request explicit permission for the specific external folder and resume the original operation after approval, rather than forcing copies, new chats, or shell workarounds. #452 separately proposes directory-handle-backed execution for authorized roots.
This complements this issue's narrower trusted-result handoff: an authenticated, provenance-bound exact-file read capability may be appropriate for a tool-generated artifact. Text containing a returned path alone must not silently mint broader folder or write authority. Keep that narrow result capability distinct from the user's explicit additional-folder grant. Both linked changes remain proposals, not implemented audit outcomes.
Broccolito commentedon Oct 24, 2026
Issue #437: Read completed connector output in place
Issue · Host PR #454 · merged main source
Historical desktop/browser/CLI observations used f227 artifacts, accepted via the reviewed production-equivalence comparison; exact-main CI/build/smoke is attributed separately below.
Problem. A connector returned a valid local result path that Developer could not read through its workspace jail, forcing a copy/cwd workaround.
Fix and UX. The original path enters the ordinary exact human folder-consent flow, then the selected read uses retained read-only authority. A returned path string never grants permission by itself. Allow once can read the result where it was created without creating a session grant or widening to write access. Connectors retain their documented job-ID result readers.
Validation. Final native C2 OMOP and C4 CDW each passed a four-pair workflow: original returned result path, normal exact read-only Allow once and in-place Developer read. Each 69-byte synthetic result matched its recorded contents/identity; the observed tool arguments target the original file. The folder-authority regression additionally checks no staged workspace copy, no session grant, write refusal and wrong-session refusal. This passed within the 14-test target. See current Rust CI and Windows bounded-file checks for their separately scoped software evidence.
Limits. Recorded calls and original-file identity establish this handoff; there was no exhaustive filesystem-copy trace. This is not arbitrary trust in tool-returned paths or clinical-query validation. Windows connector chunked result reading remains explicitly unsupported; local files exist, but no Windows GUI connector handoff/parity is claimed.
Recommendation. Keep returned paths as requested targets and use the normal scoped consent flow before access; avoid shell-copy or cwd-change workarounds.
Merged-main verification. PR454 is merged at
0580110; main Rust CI, frontend CI and related checks finished 20 successes/one skipped (17 push successes plus three landing/deployment checks; these are not security-test counts). Normal main build manifest SHA256:38cc2979c7da104cb623975bac7f6922a085e834a1be5c18e961d7f26ea811fc; shipping receipt:e6e1d8957d8d0b22a9aae814011a1e028c5d279848ffabbf4c6d0c4edf3c0112. Actual main01 smoke separately recorded four pairs—three reads/one typed Deny—and three unchanged canaries; it does not rerun/recount the historical 81-pair cohort.Submission record. Manuscript v1.1 local Supplementary Data S1: Supplementary Data S1 - BioRouter Security Audit - 2026-10-24.zip; manifest SHA256 4f0c0c110ca0b07a29d5281870227f7b36c744a0f37ccb499b8ef1283dea116e. This is a user/submission package, not a claim of public upload. Public PR/source/CI links above provide the public implementation proof.