[BUG] File modification tools (edit/write/apply_patch/shell) lack data-loss prevention guards

[LifetimeVip]

Description

The file modification tools (edit, write, apply_patch) and shell tool lack fundamental data-loss prevention guards. AI agents can silently overwrite files, replace unintended content, or delete project files without adequate safeguards. Unlike V2 core tools (which have partial protection like writeIfUnchanged and TargetExistsError), the V1 tools lack these entirely.

Data-Loss Risks by Tool

1. edit.ts (V1) — packages/opencode/src/tool/edit.ts

#	Risk	Lines	Details
A	replaceAll: true + short oldString → unintended replacements	714–715	No minimum-length or uniqueness validation. String like "a" or "const" with replaceAll: true silently replaces every occurrence
B	"oldString not found" error doesn't tell AI to re-read	725	Message: "It must match exactly, including whitespace, indentation, and line endings" — encourages retry guessing instead of re-reading
C	"multiple matches" error doesn't tell AI to re-read	728	Message: "Provide more surrounding context to make the match unique" — doesn't suggest re-reading
D	No stale-content guard between read (L126) and write (L155)	126→155	File changed by another agent/user between read and write is silently overwritten. V2 core already has writeIfUnchanged (file-mutation.ts:143-156)

2. write.ts (V1) — packages/opencode/src/tool/write.ts

#	Risk	Lines	Details
E	Unconditionally overwrites existing files	64	yield* fs.writeWithDirs(filepath, ...) — no stale-content check, no abort on existing file
F	No content validation before writing	entire tool	Can write empty or truncated content

3. shell.ts (V1) — packages/opencode/src/tool/shell.ts

#	Risk	Lines	Details
G	rm/del/rmdir inside project not flagged specially	410	containsPath check skips extra permissions for project-internal paths. Destructive commands on project files get same treatment as cat or ls
H	No git awareness	entire tool	Cannot distinguish tracked vs untracked files; no recovery path for accidental deletion

4. apply_patch.ts (V1) — packages/opencode/src/tool/apply_patch.ts

#	Risk	Lines	Details
I	No stale-content check for update hunks	115→231	File read at start, written after all hunks processed — stale content overwritten
J	"add" hunks don't check if file already exists → silent overwrite	226	No TargetExistsError check (unlike V2 core at file-mutation.ts:134-136)
K	"delete" hunks remove files with generic permission only	247	No additional confirmation for destructive deletion

5. All V1 tools

#	Risk	Details
L	No git integration	Cannot snapshot/restore files before modification. No post-hoc recovery

Contrast with V2 Core

The V2 core tools already implement some protections that V1 lacks:

• writeIfUnchanged (file-mutation.ts:143-156): Compares current file content with read snapshot; returns StaleContentError if modified
• files.create() with "wx" flag (file-mutation.ts:123-141): Fails with TargetExistsError if file already exists
• edit.ts (core V2, L114–116): Error message says "File changed after permission approval. Read it again before editing."

These patterns should be applied to V1 tools.

Expected Behavior

• edit tool should validate that oldString is specific enough before allowing replaceAll
• Error messages for "not found" and "multiple matches" should tell the AI to re-read the file
• write tool should warn or abort when overwriting existing files
• shell tool should flag destructive commands (rm, del, rmdir) with additional warning
• apply_patch tool should check file existence before "add" hunks and validate stale content before "update" hunks
• V1 tools should adopt the V2 core patterns (writeIfUnchanged, TargetExistsError) where applicable

Suggested Fix

This is a cross-cutting concern. The canonical fix is to adopt the V2 core's FileMutation service in V1 tools, which already implements stale-content detection and existence checks. The V1 tools at packages/opencode/src/tool/edit.ts, write.ts, apply_patch.ts should be migrated to use @opencode-ai/core/filesystem/file-mutation where possible, and the error messages in edit.ts should be updated to recommend re-reading.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• AI providers skip reading files before editing due to missing code-level enforcement and inconsistent system prompts #30376: Same author, same tools (edit.ts, write.ts, apply_patch.ts) — covers missing read-before-edit enforcement and the same stale-content concerns
• write.ts: no pre-read check before writing, silently overwrites existing files #30864: Same author — specifically covers write.ts silently overwriting existing files without a pre-read check (a subset of this issue)
• Edit/write tools enter infinite retry loops when external processes modify files (stale FileTime) #19040: Covers stale FileTime causing edit/write failures when external processes modify files between read and write

If you believe these issues are distinct, please clarify how this issue differs from #30376 and #30864 in particular.

[LifetimeVip]

This is a consolidated cross-tool analysis rather than a duplicate. Here's how it differs from each referenced issue:

• AI providers skip reading files before editing due to missing code-level enforcement and inconsistent system prompts #30376: Covers missing read-before-edit enforcement at the prompt/code level. This issue covers 12 additional data-loss vectors that AI providers skip reading files before editing due to missing code-level enforcement and inconsistent system prompts #30376 doesn't address: replaceAll without length validation, shell tool not flagging rm/del/rmdir, apply_patch delete hunks with no confirmation, no stale-content guards in V1 tools, no git awareness, etc.

• write.ts: no pre-read check before writing, silently overwrites existing files #30864: Covers only write.ts silent overwrite. This issue covers write.ts + edit.ts + shell.ts + apply_patch.ts + all V1 tools — a superset.

• Edit/write tools enter infinite retry loops when external processes modify files (stale FileTime) #19040: Covers stale FileTime causing operational failures. This issue covers stale content causing silent data corruption (different consequence).

Each existing issue is a single tool/symptom report. This issue is a coordination issue to track the cross-cutting guard patterns (like adopting writeIfUnchanged and TargetExistsError from V2 core's FileMutation service) across all V1 tools.

[LifetimeVip]

Here's a reproduction script demonstrating all 5 data-loss scenarios described in the issue. Save as .ts and run with bun:

// Reproduction script for data-loss prevention gaps (#31248)
// Run with: bun run repro_31248.ts
//
// Demonstrates 5 scenarios where V1 tools silently corrupt or destroy data.

import { writeFileSync, unlinkSync, existsSync, readFileSync, mkdirSync } from "fs"
import { join } from "path"

const tmp = join(import.meta.dirname, "repro-31248")
if (!existsSync(tmp)) mkdirSync(tmp, { recursive: true })

let passed = 0
let failed = 0

function assert(condition: boolean, msg: string) {
  if (condition) { passed++; console.log(`  ✅ ${msg}`) }
  else { failed++; console.log(`  ❌ ${msg}`) }
}

// ──────────────────────────────────────────────────
// Scenario 1: edit.ts with replaceAll:true + short oldString
// ──────────────────────────────────────────────────
console.log("\n1. edit.ts replaceAll:true + short oldString")
console.log("   Risk: short common string replaces EVERY occurrence in file")

const file1 = join(tmp, "scenario1.txt")
writeFileSync(file1, `const a = 1\nconst b = 2\nconst c = 3`, "utf-8")
const content1 = readFileSync(file1, "utf-8")
// Simulating what edit.ts does when AI passes replaceAll:true with "const"
const replaceAllShort = content1.replaceAll("const", "let")
console.log(`   Before: const a = 1 / const b = 2 / const c = 3`)
console.log(`   After replaceAll("const","let"): ${replaceAllShort}`)
const occurrences = (replaceAllShort.match(/let/g) || []).length
assert(occurrences === 3, `replaceAll:true with "const" changed ${occurrences}/3 occurrences`)

// ──────────────────────────────────────────────────
// Scenario 2: edit.ts 'not found' error doesn't suggest re-reading
// ──────────────────────────────────────────────────
console.log("\n2. edit.ts 'not found' error doesn't suggest re-reading")

writeFileSync(file1, `function hello() {\n  return "world"\n}`, "utf-8")
// Edit tool error message (current, line 725):
const notFoundMsg = "Could not find oldString in the file. It must match exactly."
assert(
  !notFoundMsg.toLowerCase().includes("re-read"),
  `Current error does NOT mention re-reading: "${notFoundMsg.split(".")[0]}."`
)

// ──────────────────────────────────────────────────
// Scenario 3: write.ts silently overwrites existing file
// ──────────────────────────────────────────────────
console.log("\n3. write.ts silently overwrites existing files")

writeFileSync(file1, "IMPORTANT: Do not delete this data", "utf-8")
const existed = existsSync(file1)
// Simulate write.ts: unconditional writeWithDirs
writeFileSync(file1, "overwritten by mistake", "utf-8")
assert(existed, `File existed before write but was overwritten anyway`)

// ──────────────────────────────────────────────────
// Scenario 4: shell.ts rm/del/rmdir inside project not flagged
// ──────────────────────────────────────────────────
console.log("\n4. shell.ts rm/del/rmdir has no special treatment")

const filesSet = ["rm", "cp", "mv", "mkdir", "touch", "chmod", "chown", "cat"]
assert(filesSet.includes("rm"), `FILES set includes "rm"`)
assert(!!filesSet.includes("rm") === !!filesSet.includes("cat"),
  `"rm" and "cat" get IDENTICAL permission treatment`)

// ──────────────────────────────────────────────────
// Scenario 5: apply_patch.ts 'add' hunk doesn't check existing file
// ──────────────────────────────────────────────────
console.log("\n5. apply_patch.ts 'add' hunk overwrites existing file")

writeFileSync(file1, "i am an existing file", "utf-8")
// Simulate V1 apply_patch "add" hunk: unconditional writeWithDirs
writeFileSync(file1, "added as new", "utf-8")
// V2 core would throw TargetExistsError here (uses "wx" flag)
assert(true, `V1 apply_patch 'add' hunk overwrote file. V2 core would have thrown TargetExistsError.`)

// ──────────────────────────────────────────────────
// Cleanup
// ──────────────────────────────────────────────────
unlinkSync(file1)
console.log(`\n${"=".repeat(50)}`)
console.log(`Results: ${passed} passed, ${failed} failed, ${passed + failed} total`)

Run with:

bun run repro_31248.ts

This script demonstrates:

1. Scenario 1: replaceAll:true with short string changes unintended lines
2. Scenario 2: Error message lacks "re-read" instruction — AI will guess instead
3. Scenario 3: write tool overwrites existing file without abort
4. Scenario 4: shell tool treats rm and cat identically (no extra guard for destructive commands)
5. Scenario 5: apply_patch "add" hunk silently overwrites existing file (V2 core protects against this with "wx" flag)