Bug #18-21: v4 Hotfixes

Status: RESOLVED in v4.0.1 Category: Multiple (Edit Matching, Path Normalization, Batch Operations, Pipeline) Severity: High (tools failing or panicking in production) Resolution Date: 2026-03-04

Bug #18: Literal Escape Normalization

Problem

Claude Desktop sometimes sent literal two-character sequences \n and \t instead of actual newline/tab characters in old_text. The edit matching compared these against the file’s real newlines and failed.

Root Cause

The MCP JSON transport correctly escapes newlines in strings, but some Claude Desktop versions double-escaped them. The old_text parameter contained the literal characters \, n instead of a newline byte.

Solution

• Added fallback normalization: if initial match fails, try replacing literal \n/\t with actual newline/tab
• Added old_str/new_str parameter aliases — Claude Desktop sometimes sends these instead of old_text/new_text

Files Changed

• main.go — Parameter alias handling in edit_file and multi_edit handlers

---

Bug #19: WSL Path in search_files

Problem

search_files handler was missing the NormalizePath() call that all other handlers had. WSL paths like /mnt/c/Users/... were passed directly to the engine without conversion to Windows paths.

Root Cause

When the 16 tools were consolidated in v4.0.0, the search_files handler was written without the path normalization step that other handlers included.

Solution

Added NormalizePath() call at the start of the search_files handler, matching all other tool handlers.

Files Changed

• main.go — search_files handler

---

Bug #20: batchManager.SetEngine() Missing

Problem

batch_operations panicked with a nil pointer dereference because batchManager.SetEngine() was never called after engine initialization.

Root Cause

The BatchManager requires a reference to the engine for executing operations, but the initialization sequence in main.go created the batch manager without linking it to the engine.

Solution

Added batchManager.SetEngine(engine) call after engine creation in main.go.

Files Changed

• main.go — Engine initialization sequence

---

Bug #21: Pipeline formatPipelineResult Failures

Problem

formatPipelineResult() crashed in compact mode when pipeline steps had nil or missing result fields. The function accessed map keys and struct fields without nil checks.

Root Cause

Pipeline steps that were skipped (via conditions) or that produced no output had nil result maps. The compact formatter assumed all fields were present.

Solution

Added nil checks and safe field access throughout formatPipelineResult(). Steps with no results now produce a safe empty summary instead of panicking.

Files Changed

• main.go — formatPipelineResult() function

---

Testing

All four bugs are covered by regression tests:

go test ./tests/ -run TestBug18 -v
go test ./tests/ -run TestBug19 -v
go test ./tests/ -run TestBug20 -v
go test ./tests/ -run TestBug21 -v

Test file: tests/bug19_20_21_test.go, tests/bug18_literal_escapes_test.go