Summary
We encountered a serious path consistency issue while using an Agent Session to edit workspace files in a cloud-hosted Anna App. Absolute paths provided to the Agent are not reliably passed through unchanged to fs_read_file, fs_write_file, and other fs_* tools. Instead, the Agent may trim or convert an absolute path into a relative path based on what it believes the Sandbox root to be, and then submit that relative path to the filesystem tool.
When the cloud backend workspace, the cloud Agent filesystem root, and the user’s local Agent root do not match, this implicit conversion can make the target files inaccessible. More seriously, it can cause content to be written into a different or historical workspace.
We believe filesystem tools should support absolute paths with deterministic semantics and use the supplied path unchanged. If the security model does not permit access to a path, the tool should reject it explicitly instead of silently converting it into a relative path.
Use Case
Our application creates a PPT task workspace in the cloud. A Page Authoring Agent reads the workspace configuration, outline, and TSX page source, and then modifies only the designated TSX file.
For the affected task, the backend recorded the workspace as:
/home/agent/anna-workspace/ppt/ppt-20260719-150726
The Agent needed to read files including:
/home/agent/anna-workspace/ppt/ppt-20260719-150726/requirements.json
/home/agent/anna-workspace/ppt/ppt-20260719-150726/outline.json
/home/agent/anna-workspace/ppt/ppt-20260719-150726/style-guide.md
/home/agent/anna-workspace/ppt/ppt-20260719-150726/slides/<page_id>.tsx
These are valid absolute paths. The files existed and were accessible to the backend.
Actual Behavior
1. Absolute paths are implicitly converted into relative paths
Even when the prompt contains a complete absolute path, the Agent may trim it to a path relative to its assumed Sandbox root before calling fs_read_file. For example:
Path provided to the Agent:
/home/agent/anna-workspace/ppt/setting.json
Path actually submitted to fs_read_file:
ppt/setting.json
From the caller’s perspective, it is not possible to determine whether this conversion occurs while the model generates the tool arguments, inside the Agent Session SDK, or in the filesystem tool proxy. However, the externally observable Agent Session behavior is that the absolute path supplied by the caller is not executed unchanged.
This makes absolute paths nondeterministic. A caller cannot identify the exact file to access by supplying its absolute path alone.
2. The cloud backend path and Agent filesystem path do not match
The backend path for this task was under:
/home/agent/anna-workspace
However, the online filesystem client roots discovered by the Agent Session were:
/Users/<user>/anna-workspace
/data/workspace
In this setup:
/home/agent/anna-workspacewas used by the cloud PPT backend to create and validate files./data/workspacewas exposed as the cloud Agent filesystem client’s working directory./Users/<user>/anna-workspacewas exposed by the user’s local Agent.
There was no stable, explicit mapping among these three paths.
The cloud Agent runs with /home/agent as its home directory, so it is reasonable for a caller to assume that its default workspace would be /home/agent/anna-workspace. In practice, however, the root visible to the fs_* tools may be /data/workspace. The Agent Session does not provide a reliable mechanism for declaring which filesystem client and client-side path correspond to a given backend absolute path.
3. The Agent may fall back to another workspace and write the wrong file
Because the current task, ppt-20260719-150726, did not exist under the roots visible to the Agent filesystem tools, some Agent calls returned errors such as:
File not found: ppt/ppt-20260719-150726/requirements.json
Directory not found: ppt/ppt-20260719-150726
More seriously, after listing directories, the Agent found a historical task:
ppt/ppt-20260719-143941
It then read that historical task’s requirements.json, outline.json, style-guide.md, and Authoring Kit, and wrote pages generated for the current task into the historical task directory:
/data/workspace/ppt/ppt-20260719-143941/slides/<new_page_id>.tsx
The Agent ultimately reported that the page had been completed, but the target TSX file in the current task had not changed at all. The backend fingerprint check therefore correctly reported:
The Agent completed its response but did not actually modify the current page TSX.
This shows that the issue can cause more than a simple “file not found” failure. It can also result in cross-workspace writes and contamination of historical tasks.
Minimal Reproduction
-
Create the following file in a cloud service:
/home/agent/anna-workspace/ppt/example/setting.json -
Create an Agent Session with access to the
fs_*tools. -
Instruct the Agent to read this exact absolute path:
/home/agent/anna-workspace/ppt/example/setting.json -
Inspect the tool arguments generated by the Agent and the root directory actually accessed by the filesystem tool.
-
When the filesystem client root is
/data/workspace, check whether the Agent:- converts the argument to
ppt/example/setting.json; - returns a file-not-found error;
- attempts to enumerate other online clients or other
ppt-*directories; - eventually reads from or writes to another workspace.
- converts the argument to
Expected Behavior
When the caller or Agent supplies an absolute path to a filesystem tool:
/home/agent/anna-workspace/ppt/example/setting.json
the tool should do one of the following:
- Access the exact path. Use the absolute path unchanged and complete the read or write operation if it falls within the authorized Sandbox boundary.
- Reject the path explicitly. If the path is outside the tool’s authorized root, return a structured error that includes the authorized root and the reason for rejection.
The following behaviors should not occur:
- silently removing a prefix from an absolute path;
- guessing the Sandbox root from the Agent’s previous context or memory;
- switching implicitly among multiple online filesystem clients;
- selecting a similarly named workspace when the intended workspace cannot be found;
- changing the actual read or write location without making that change visible to the caller.
Impact
This issue can affect any application that relies on an Agent Session to edit local or cloud-hosted files, especially when:
- the backend service and Agent filesystem tools run in different containers or use different mount points;
- the same user has both a cloud Agent and a local Agent connected;
- multiple historical workspaces have similar directory structures;
- the application uses file fingerprints, build artifacts, or task state to determine whether an Agent completed an edit;
- the Agent has write access, allowing an incorrect path to contaminate another task or user file.
This creates both reliability and data isolation risks. Repeating the target path more strongly in the prompt does not solve the underlying problem because path resolution and filesystem client selection remain nondeterministic.
Suggested Fix
Our preferred solution is for Anna Agent Sessions and fs_* tools to support absolute paths natively and guarantee that the path semantics of tool arguments are not changed implicitly.
At a minimum, we suggest the following capabilities:
- Tools such as
fs_read_file,fs_write_file, andfs_list_directoryshould accept absolute paths and resolve them unchanged within the Sandbox authorization boundary. - The Agent Session should explicitly expose the canonical root and client ID of the active filesystem client.
- Session creation should allow the caller to specify filesystem client or workspace mount affinity, ensuring that all reads and writes within a session target the same workspace.
- If backend paths must be mapped to filesystem tool paths, the Runtime should provide an explicit, queryable mapping instead of relying on the model to trim path strings.
- If a path is outside the authorized root or the target client is unavailable, the tool should return a structured error instead of falling back to another client or workspace.
- A Session should support restricting writes to one designated directory so that an Agent cannot write to another task after failing to locate its intended target.
If arbitrary absolute paths cannot be supported in the short term, we suggest providing a stable Workspace URI or file handle mechanism, for example:
workspace://<client_id>/ppt/ppt-20260719-150726/slides/<page_id>.tsx
The key requirement is that callers must be able to identify the file, filesystem client, and authorization scope unambiguously, and that this identifier must not be rewritten during Agent reasoning.
Conclusion
The current Agent Session filesystem behavior conflates backend absolute paths, the Agent’s assumed Sandbox path, and the roots exposed by online filesystem clients. Relative path conversion may appear to work in a single-machine, single-root environment, but it becomes unpredictable when cloud and local Agents coexist and can result in cross-workspace writes.
We hope Anna can make absolute paths, or an equivalent canonical file identifier, a first-class capability of its filesystem tools and provide Agent Sessions with explicit, stable, and verifiable filesystem boundaries.
Your analysis was right on target — the filesystem sandbox itself always accepted in-root absolute paths, but other layers were fighting against it. We’ve now made path semantics deterministic end-to-end:
What we fixed
Available in
On our radar
