# Reported issues for Patchloom

Pod holds 14 of 14 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.

Back to [Patchloom](/mcp/patchloom).

## Most discussed

### enhancement: notebook cell edit is a new op, not a doc.set special case

There is no notebook-cell edit tool. `doc.*` on a `.ipynb` file edits the raw JSON, where each cell `source` is an array of lines. That is awkward compared with a dedicated notebook edit.

## Decision

Out of scope unless we add a real cell op (`notebook.edit` or similar) with its own tests. Do not special-case `.ipynb` inside `doc set` and pretend the JSON shape is a cell editor.

File this so the gap is recorded. No implementation until someone chooses the op shape.

[Read the thread](https://github.com/patchloom/patchloom/issues/2619) · 2026-09-24 · closed · outside contributor · 1 comment

### bug(mcp): MCP server ignores .patchloom.toml [exclude] globs

## Summary

The MCP server ignores `.patchloom.toml` `[exclude] globs`. The CLI honors them for search and every walker-based op; MCP `search_files` (and presumably `batch_replace`, `batch_tidy`, `list_files`) walk the excluded files too. `[write_policy]` is honored because writes go through the engine, so the config is partially applied, which is worse than not at all: an agent that excluded `*.log` or `vendor/**` in config sees them via MCP.

## Reproduction

```sh
printf '[exclude]\nglobs =…

[Read the thread](https://github.com/patchloom/patchloom/issues/2540) · 2026-09-17 · closed · outside contributor · 1 comment

### bug: MCP call log written with blocking std::fs on the async executor

## Summary

`log_tool_call` in the MCP server opens and appends to the call log with synchronous `std::fs` from inside `async fn call_tool`. The module documents that all sync I/O goes through `PatchloomService::blocking` / `spawn_blocking` so one slow operation cannot starve other sessions. The log write bypasses that rule and runs on the tokio executor thread after every tool call.

With a slow or hung log filesystem (network mount, full disk, `PATCHLOOM_MCP_LOG` pointing at a FIFO), every…

[Read the thread](https://github.com/patchloom/patchloom/issues/2464) · 2026-09-17 · closed · outside contributor · 1 comment

### bug: MCP execute_plan bypasses content/param/batch size limits

## Summary

Every MCP write tool applies the server resource limits in `validation.rs` (`validate_content_size`, `validate_param_size`, `validate_batch_size`: 10 MiB content, 1000-file batches, etc.). `execute_plan` does not apply any of them to inline plan operations. The same oversized payload that `create_file` rejects is accepted when wrapped in a plan, staged fully in memory on the long-lived server.

## Reproduction

`create_file` with a 50 MiB `content` is rejected by…

[Read the thread](https://github.com/patchloom/patchloom/issues/2463) · 2026-09-17 · closed · outside contributor · 1 comment

### bug: mcp-server --http cannot bind ::1 or localhost despite recommending them

## Summary

The MCP HTTP transport builds the bind address with `format!("{host}:{port}")` and parses it as `std::net::SocketAddr`. That parser requires an IP literal and, for IPv6, bracket syntax. So `--host ::1` becomes `::1:8080` (invalid) and `--host localhost` fails outright. Yet the unauthenticated-bind refusal message at `src/cmd/mcp/transport.rs:181` tells users to "Bind 127.0.0.1, ::1, or localhost". Two of the three recommended values do not work.

## Reproduction steps

```sh…

[Read the thread](https://github.com/patchloom/patchloom/issues/2462) · 2026-09-17 · closed · outside contributor · 1 comment

### bug: invalid --dedent/--indent spec silently no-ops instead of erroring

## Summary

`dedent_content` and `indent_content` parse their numeric spec with `n.parse().unwrap_or(0)` and treat `0` as "return the content unchanged". An unparseable spec is therefore indistinguishable from a valid no-op: the command **exits 0, prints nothing, and changes nothing**.

For a tool whose contract is typed, machine-readable errors for agent hosts, a silently-ignored argument is the worst available outcome — the agent believes its edit was applied.

## Code

`src/write.rs:497`:…

[Read the thread](https://github.com/patchloom/patchloom/issues/2378) · 2026-09-10 · closed · outside contributor · 1 comment

### bug: byte-indexed indent measurement panics on Unicode whitespace (4 reachable sites)

## Summary

Four production sites measure leading indentation as a **byte** count derived from `trim_start()`, then use that count as a **string slice index on a different line**. `trim_start()` strips all Unicode whitespace, so any file indented with (or merely containing) a multi-byte whitespace character — U+00A0 NBSP, U+3000 ideographic space, U+2007, U+202F — makes the slice land mid-character and panics.

All four are reachable from user input and all four reproduce today on `main`…

[Read the thread](https://github.com/patchloom/patchloom/issues/2377) · 2026-09-10 · closed · outside contributor · 1 comment

### enhancement: read_file line aliases without a silent size cap

MCP `read_file` maps to plan op `read` (`path`, optional `lines` as `start:end`). Measured on `8d47c47a`:

- No size or line cap. A large file comes back as one JSON string.
- The payload is the write-result envelope (`files_changed`, `applied: false`, `changes: []`) plus the content, with no line numbers.
- `offset` / `limit` and `start_line` / `end_line` fail with `-32602` unknown field. Only `lines` is accepted. Other tools do accept aliases (`from`/`to`, `key`, `file`).

## Constraint

A…

[Read the thread](https://github.com/patchloom/patchloom/issues/2616) · 2026-09-24 · closed · outside contributor · 0 comments

## Most recent

### bug: concurrent MCP writes on one file report success and drop updates

Concurrent `tools/call` writes on one MCP server process can each report success while only one update remains on disk.

## Repro

Debug binary built from `8d47c47a`. Pipelined stdio (all requests in one write, before reading responses), empty temp dir, `f.txt` with `tok0`..`tok19`:

```python
call(".", [("replace_text", {"path":"f.txt","old":f"tok{i}\n","new":f"DONE{i}\n"}) for i in range(20)])
```

Observed 2026-09-23: 20/20 `ok: true`, `applied: true`, and `f.txt` contained `DONE` once.…

[Read the thread](https://github.com/patchloom/patchloom/issues/2610) · 2026-09-24 · closed · outside contributor · 0 comments

### fix: ignore EPIPE on remaining doc and undo --list dumps

## Summary

After schema/agent-rules (#2593) and replace jsonl / tidy check (#2597), remaining human dumps still panic on EPIPE:

- `undo --list` (session listing `println!` loop)
- `doc get` / `doc keys` (single `println!("{output}")` at end of `src/cmd/doc.rs`)

`--json` on these commands already goes through the same `println!` for doc (the JSON string is printed that way).

## Expected

`write_stdout_ignore_epipe` and a non-panic exit when stdout is closed, matching `schema` / `list-files`…

[Read the thread](https://github.com/patchloom/patchloom/issues/2600) · 2026-09-20 · closed · outside contributor · 0 comments

### fix: ignore EPIPE on replace jsonl and tidy check listings

## Summary

`replace --jsonl` and `tidy check` panic on EPIPE (`failed printing to stdout: Broken pipe`, exit 101) when stdout is closed after a few bytes. JSON schema / list-files / read already use `write_stdout_ignore_epipe`. `--json` replace already does. `--jsonl` still uses `println!` per line (`emit_replace_jsonl`). `tidy check` text listings do the same.

## Repro

Close stdout immediately after spawn:

```
patchloom --jsonl replace fn  --new xx src --glob '*.rs'
patchloom tidy check…

[Read the thread](https://github.com/patchloom/patchloom/issues/2597) · 2026-09-20 · closed · outside contributor · 0 comments

### fix: SEARCH/REPLACE inner fences, whole-line close, mixed Begin Patch

## Summary

Follow-up to SEARCH/REPLACE parse (#2592). Three remaining grammar holes:

1. DiffFenced unwrap ran when **any** line started with triple backticks, so dest-present SEARCH whose old/new contain a markdown fence dropped those lines and returned `no_matches`.
2. Close `>>>>>>> REPLACE` was a substring. REPLACE text `see >>>>>>> REPLACE in docs` applied as `see ` with no parse error.
3. SEARCH first then a later col-0 `*** Begin Patch` applied SEARCH only and dropped the Begin Patch…

[Read the thread](https://github.com/patchloom/patchloom/issues/2595) · 2026-09-20 · closed · outside contributor · 0 comments

### fix: ignore EPIPE on schema prompt and agent-rules dumps

## Summary

`schema --format prompt` and `agent-rules` still dump with `print!`. JSON `schema` already uses `write_stdout_ignore_epipe`. `agent-rules` output is ~65KiB, at the typical pipe buffer, so `| head` can panic with `failed printing to stdout: Broken pipe` once the dump grows or the helper closes stdout before the write finishes.

## Expected

Those two dumps use `write_stdout_ignore_epipe` and exit 0 on EPIPE, matching `schema` JSON / `list-files` / `read`.

## Files

-…

[Read the thread](https://github.com/patchloom/patchloom/issues/2593) · 2026-09-20 · closed · outside contributor · 0 comments

### fix: SEARCH/REPLACE CRLF parse and whole-line dest dashes

## Summary

CLI `patch apply` of a CRLF SEARCH/REPLACE document against an LF file returns `error_kind: no_matches` and does not write. Dest-less SEARCH whose old text contains `-------` is parsed as dest-present with a garbage path (`error_kind: not_found`).

## Repro (CRLF)

File `code.rs`: `fn old() {}\n`

Patch (CRLF):

```
<<<<<<< SEARCH
code.rs
-------
fn old() {}
=======
fn new() {}
>>>>>>> REPLACE
```

`patchloom patch apply change.sr --apply --json` looks for `"\r\nfn old() {}\r"` and…

[Read the thread](https://github.com/patchloom/patchloom/issues/2592) · 2026-09-20 · closed · outside contributor · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/patchloom/patchloom/issues).