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.
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 · 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
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 · 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 listingprintln!loop)doc get/doc keys(singleprintln!("{output}")at end ofsrc/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 · 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).