Struct EditFile 

pub struct EditFile { /* private fields */ }

Targeted file edit. Locks the file, re-reads under lock, verifies the unique-match invariant, writes to a temp sibling, and atomically renames into place — fixing the v0.1 TOCTOU race between read and write.

Unsandboxed by default. Use EditFile::with_sandbox when exposed to hostile LLM output.

Lockfile name is predictable

The sidecar lock lives at .<filename>.agnt-edit.lock in the same directory as the target. The name is deterministic by design — it has to be, so two agnt processes editing the same file on the same host coordinate correctly. The tradeoff is that a different local process on the same machine can pre-create the lockfile and hold the exclusive lock, causing every EditFile call on that target to block or fail. That is a local-user DoS, not a sandbox escape: it requires write access to the target’s parent directory, which is already out of the agent’s threat model (v0.2 Threat Model § “local untrusted users”). If you need multi-tenant isolation, put each agent in its own bwrap/container/landlock view — the lockfile pattern is designed for the single-tenant case.

Implementations

impl EditFile

pub fn new() -> Self

pub fn with_sandbox(sandbox: Arc<FilesystemRoot>) -> Self

Trait Implementations

impl Default for EditFile

fn default() -> Self

Returns the “default value” for a type.

impl Tool for EditFile

fn name(&self) -> &str

The tool’s name — used by the model to invoke it and for dispatch.

fn description(&self) -> &str

Human-readable description sent to the model as part of the tool list. This is the primary steering mechanism for tool selection.

fn schema(&self) -> Value

JSON Schema describing the tool’s arguments.

fn call(&self, args: Value) -> Result<String, String>

Execute the tool synchronously. Return a string result or an error message. Callers must enforce result-byte caps and envelope framing before persisting or feeding back to the model.