Skip to main content
Vireon DynamicsLiminal AIUse casesMulti File EditsFSL-1.1-MIT · free to use

Use case · Updated 2026-06-02

Multi-file edits

Liminal treats the filesystem as the source of truth: targeted replacements, diff-based edits, atomic multi-file transactions, and optional streaming for large files — always with locks and approvals on destructive paths.

Two always-on write modes

write_file creates, overwrites, or appends whole files. edit_file applies replacements or a fuzzy unified diff on an existing path. Both are always registered (not behind lazy activation) because code is the agent’s substrate.

The files_edit family adds move_file, copy_file, mkdir_p, delete_file (approval-gated), and multi_file_apply for batched changes that roll back together if any step fails.

Large files and truncation recovery

When AGENT_WRITE_STREAM_SINK is on, large payloads stream into .agent_write_staging/ as tool-call args arrive, avoiding context blowups. If a completion hits max_tokens mid-write, length-resume can continue from a manifest instead of losing the turn. AGENT_WRITE_INTEGRITY_NUDGE warns when a file looks truncated.

Locks and path safety

Tools declare resourceLocks; the ResourceLockManager acquires file:read:, file:write:, and shell: locks in sorted order to prevent deadlocks. path_guard blocks escapes outside the workspace root.

Typical multi-file session

  • Read affected files and importers.
  • Apply edit_file or multi_file_apply with a single logical change set.
  • run_lint on changed paths; run_tests if behavior changed.
  • git_diff for human review; git_commit when ready.