Skip to main content
The palyra.fs tool family provides the agent with controlled, scoped access to the host filesystem. It is divided into two primary categories: Workspace Tools (scoped to agent roots and session focus) and the OS File Tool (for broader system access in local desktop profiles). All filesystem operations are subject to strict path canonicalization, containment checks, and safety redaction.

Workspace Scoping and Path Resolution

Workspace tools operate on an ordered list of workspace roots derived from the agent configuration, session focus, and run-launch context. Path resolution ensures that an agent cannot traverse outside its assigned boundaries.

Scoping Hierarchy

The workspace_scope module derives the active roots for a tool call by layering dynamic context over static configuration:
  1. Run-Launch Context: Extra roots, launch CWD, and exact file grants supplied via the RunLaunchCliContext in the run’s parameter delta crates/palyra-daemon/src/application/tool_runtime/workspace_scope.rs#45-51.
  2. Session Focus: The directory the operator is currently focused on in the UI, resolved as an ActiveWorkspaceRoot crates/palyra-daemon/src/application/tool_runtime/workspace_scope.rs#32-38.
  3. Agent Roots: The baseline directories configured for the specific agent crates/palyra-daemon/src/application/tool_runtime/workspace_scope.rs#85-93.

Security and Resolution

Every path is canonicalized before containment checks. To prevent TOCTOU (Time-of-Check Time-of-Use) attacks, file reads re-resolve the handle after opening to ensure the path wasn’t swapped crates/palyra-daemon/src/application/tool_runtime/workspace_file.rs#3-9. Data Flow: Workspace Path Resolution Sources: crates/palyra-daemon/src/application/tool_runtime/workspace_file.rs#1-14, crates/palyra-daemon/src/application/tool_runtime/workspace_scope.rs#1-16

Workspace File Operations

The workspace_file module implements read, list-dir, and search tools.
Tool NameKey FunctionPurpose
palyra.fs.read_fileexecute_read_fileReads file content with optional line/byte windowing.
palyra.fs.list_direxecute_list_dirLists directory entries with metadata.
palyra.fs.searchexecute_searchRecursive grep-like search with traversal budgets.

Safety and Redaction

Text output from these tools passes through palyra-safety before reaching the model. If secrets are detected, the content is replaced with placeholders (e.g., <redacted>), and the redacted flag is set in the output crates/palyra-daemon/src/application/tool_runtime/workspace_file.rs#118-149. Binary files are never returned as text; instead, they provide a SHA-256 digest and a short base64 prefix crates/palyra-daemon/src/application/tool_runtime/workspace_file.rs#114-117. Sources: crates/palyra-daemon/src/application/tool_runtime/workspace_file.rs#37-51, crates/palyra-safety/src/lib.rs#1-9

Palyra Patch Document Format

The palyra.fs.apply_patch tool uses a specialized grammar designed for LLM reliability. It supports atomic application of multi-file changes.

Patch Grammar

The parser, located in palyra-common, recognizes several operation headers:

Patch Execution Pipeline

Execution follows a strict fail-closed sequence:
  1. Dry Run: The patch is parsed and planned against the filesystem without writing crates/palyra-daemon/src/application/tool_runtime/workspace_patch.rs#145-148.
  2. Risk Assessment: The plan is checked for high-risk operations (e.g., deleting security configs or lockfiles) crates/palyra-daemon/src/application/tool_runtime/workspace_patch/checkpoint_flow.rs#110-113.
  3. Preflight Checkpoint: A snapshot of the affected files is captured in the JournalStore crates/palyra-daemon/src/application/tool_runtime/workspace_patch/checkpoint_flow.rs#131-150.
  4. Atomic Apply: Changes are written to disk. If any part fails, a best-effort rollback is performed crates/palyra-common/src/workspace_patch.rs#1-7.
  5. Post-change Checkpoint: A final snapshot is taken to verify the mutation crates/palyra-daemon/src/application/tool_runtime/workspace_patch/checkpoint_flow.rs#4-8.
Data Flow: Patch Execution with Checkpointing Sources: crates/palyra-daemon/src/application/tool_runtime/workspace_patch.rs#1-12, crates/palyra-daemon/src/application/tool_runtime/workspace_patch/checkpoint_flow.rs#82-108, crates/palyra-common/src/workspace_patch.rs#124-133

OS File Access

The palyra.fs.os_file tool provides access to the broader operating system. It is intended for local desktop profiles where the agent acts as a user assistant.

Path Access Modes

The OsFilePolicy determines what the tool can reach:

Supported Operations

The tool implements a flat schema for multiple operations via the OsFileOperation enum: Stat, Read, Write, Copy, Move, DeleteFile, DeleteEmptyDir, Mkdir, ListDir, and Search crates/palyra-daemon/src/application/tool_runtime/os_file.rs#89-102. Sources: crates/palyra-daemon/src/application/tool_runtime/os_file.rs#17-42, crates/palyra-daemon/src/application/tool_runtime/os_file.rs#107-112

Implementation Details

Key Classes and Functions

Resource Limits

To prevent DoS or excessive resource consumption, all tools enforce hard limits: Sources: crates/palyra-daemon/src/application/tool_runtime/workspace_file.rs#53-71, crates/palyra-common/src/workspace_patch.rs#37-50