Tau Tool Verification File Shell

Shell mutation and directory-lock mode

Older Tau versions exposed explicit shell mode: ro / mode: rw arguments. Current ext-shell derives shell read/write behavior from manual dir_lock coverage, not from command-content mutation detection. A shell command is treated as read-only unless the caller already holds a matching manual directory update lock; under that same-owner manual lock it is covered as a read/write command. Do not expect a mode argument unless it is present in the live tool schema.

When verifying ext-shell shell, check both sides of that rule: shell commands without same-owner manual-lock coverage bypass conflicting update locks (and use read-only bind enforcement when available), while shell commands run by the owner under a matching manual dir_lock are covered by that lock and keep it active. When only provider/native shell_command is available, report that ext-shell directory-lock and historical mode: ro checks are not applicable to that tool schema.

Both non-Codex editor implementations are provider-visible as edit, so first identify the advertised schema. Ordinary models use the exact-text internal replace implementation described below. An explicit shell:tool-style:edit tag or tool_policy.default_shell_tool_style: edit selects the legacy line-coordinate internal edit implementation, also as provider-visible edit.

The line-coordinate schema selected by either mechanism requires each edit entry to include start_line, end_line_exclusive, newText, and context_line; it replaces the original half-open line range start_line..end_line_exclusive with newText as whole replacement lines. Empty insertion ranges use start_line == end_line_exclusive; non-empty replacements cover start_line through end_line_exclusive - 1. To replace read output lines A through B, use start_line: A and end_line_exclusive: B + 1. All edit ranges use the original file numbering as if applied simultaneously, so the tool must reject overlapping ranges before changing the file. Unlike read, edit must not clip ranges: both line slots must be at most total_lines + 1, and end_line_exclusive must be at least start_line. When non-empty newText lacks a trailing line ending, edit normalizes it into a full line using surrounding/replaced content as needed; explicit line endings in newText are preserved, so mixed line endings are allowed. That line-coordinate editor supports file creation: missing files are treated as empty, and missing parent directories are created only after the request validates. To create a file, insert with start_line: 1, end_line_exclusive: 1, and an empty context_line. The model-visible result should stay minimal: edits, changed, new_max_valid_start_line, and total_bytes; new_max_valid_start_line is after-edit state and must not be confused with original range validation.

The line-coordinate editor requires a per-entry context_line string matching the original line immediately before start_line, excluding any line ending. Use an empty context_line when start_line is 1. EOF appends to a non-empty file must use the original last line as context_line; empty/missing-file creation uses an empty context_line. For ease of agent use, trailing literal \r and \n characters in the supplied context line are accepted and trimmed before matching; embedded \r or \n characters remain malformed. A malformed context line, missing context line, or context-line mismatch must leave the file unchanged. A mismatch returns read-like line-numbered content details around the expected context line plus up to 10 existing lines before and after it, with invalid UTF-8 and truncation handled like read; the BOF virtual context line is not rendered as a fake numbered line and is reported as context_line_number: 0. The line-coordinate editor allows at most 100 edit entries per call. Requests with more entries must error out immediately before reading, writing, or creating parent directories. Invalid ranges, overlapping ranges, missing newText, missing or malformed context_line, malformed line fields, and context-line mismatches must leave the file unchanged. Error details should not echo raw edit requests; only purpose-built recovery details such as context-line mismatch context should be included.

For ordinary models, provider-visible edit is the internal exact-text replace implementation and accepts exactly {path, edits:[{oldText,newText}]} for one existing UTF-8 file and at most 100 entries. Verify it rejects unknown fields, empty oldText, invalid UTF-8, duplicate/nonmatching/overlapping targets, and files over 10 MiB without writing. It must match all targets in one original snapshot, after CRLF/CR-to-LF normalization and ignoring only an initial UTF-8 BOM; do not accept fuzzy Unicode, whitespace, punctuation, legacy aliases, or JSON-string preprocessing. Verify BOM and untouched mixed-ending bytes survive, inserted newlines use local source endings with LF fallback, success exposes only edits, changed, and total_bytes, and changed UTF-8 files attach the normal structured diff while no-ops attach none. With directory locking enabled it must wait on the same automatic update lock class as the line-coordinate implementation. Verify the provider definition/call/result names are edit while ext-shell lifecycle started/result events retain replace. The explicit shell:tool-style:edit selector uses the line-coordinate schema above. apply_patch should follow safe patch semantics rather than shell patch clobber semantics. Verify Add File rejects an already-existing destination and preserves its original content. Verify move hunks reject moves whose destination already exists, preserving both the source and the existing destination; a move is distinct from an explicit update/delete and must not silently clobber another file. Context, line, hunk, add, delete, and move validation failures should not silently mutate unrelated content, and all file changes that are applied before a later partial failure must be reported clearly.

apply_patch output should stay compact and should not echo the full patch text back to the agent. Its status header should name the first changed path, append ,… when multiple distinct paths changed, and show the NF file count before aggregate +N/-M diff totals; a failure before any filesystem effect should not fabricate path or count metadata. For UTF-8 files it mutates, the tool should attach structured UI-only diffs; multi-file patches should attach one structured diff per changed file. When a later hunk fails after earlier hunks have already been applied, the agent-visible error must include structured partial-mutation details for the files/paths that changed where applicable, while the UI still receives diffs and the same truthful compact path/count metadata for those applied UTF-8 changes. Invalid UTF-8 or binary-like files should not produce misleading text diffs; report any missing, duplicated, or agent-visible raw diff payloads as tool-output regressions.

Context mismatches must keep ToolError.message single-line so the normalized error header remains readable and injection-safe. Put the bounded, path-labelled expected-context excerpt in details.output, where real newlines are valid. Preserve escaped metadata paths, no-mutation evidence, and any partial-change fields/UI diffs from earlier successful hunks.

For shell truncation, independently construct the expected rendered records. total_bytes and saved artifacts count the complete UTF-8 rendering, including out / err prefixes, flags such as crlf, no_nl, and invalid-utf8, plus inserted separators. They deliberately do not report raw process payload bytes.

Other commands should adhere to pre-existing conventions and naming used in standard tools.