open-webui/open-terminal

Fork 0

mirror of https://github.com/open-webui/open-terminal.git synced 2026-11-05 01:27:28 +00:00

append + defensive replace check #141

New issue

Open

opened 2026-10-18 21:11:10 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 21:11:10 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/open-webui/open-terminal/pull/151
Author: @dvystrcil
Created: 8/1/2026
Status: 🔄 Open

Base: main ← Head: feat/insert-append-endpoints

📝 Commits (1)

e7f27be feat: insert_after/append_to_section/append + defensive replace check

📊 Changes

2 files changed (+310 additions, -0 deletions)

View changed files

📝 CHANGELOG.md (+10 -0)
📝 open_terminal/main.py (+300 -0)

📄 Description

Motivation

I noticed a recurring failure pattern when an LLM agent wants to ADD a new section to a file: it expresses the intent as a replace_file_content call with a made-up target (usually the heading it wants to add) and a replacement that starts with that same text. Since the "target" never existed in the file, this just fails with a generic "Target string not found", and the model often concludes the file was truncated and goes into an unproductive re-read loop rather than realizing it needed a different operation.

What this adds

Three companion operations to replace_file_content, for ADDING rather than replacing:

POST /files/insert_after -- insert content on a new line immediately after the first line matching an anchor substring. allow_multiple to insert after every match instead of erroring on ambiguity.
POST /files/append_to_section -- find a markdown heading by substring, append content at the end of that section (immediately before the next heading at equal-or-shallower depth, or EOF). Correctly skips past deeper sub-headings within the section.
POST /files/append -- append at end of file, handling missing trailing newlines on both sides.

Also hardens replace_file_content itself to catch the pattern directly: when target is identical to the first non-empty line of replacement, it refuses with a specific error naming the three ops above, instead of the generic "not found" message.

I know adding new endpoints is a bigger ask than a small bug fix -- happy to adjust naming/shape, split this into smaller pieces, or drop the defensive-check part if you'd rather keep replace_file_content untouched. Also totally understand if this is outside what you want in scope; no worries either way.

Testing

No test harness exists in this repo currently, so verified end-to-end against the real running server:

Defensive check correctly refuses and leaves the file untouched, with the new-ops hint in the error message.
insert_after inserts correctly after the matched anchor.
append_to_section appends before the next heading, correctly skipping past a sub-heading's body.
append appends with correct newline handling.
Regression: a legitimate replace where target != replacement's first line is unaffected by the new check.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/open-terminal/pull/151 **Author:** [@dvystrcil](https://github.com/dvystrcil) **Created:** 8/1/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `feat/insert-append-endpoints` --- ### 📝 Commits (1) - [`e7f27be`](https://github.com/open-webui/open-terminal/commit/e7f27be33591c6f4d9f9efc93bb3ed0d008d4286) feat: insert_after/append_to_section/append + defensive replace check ### 📊 Changes **2 files changed** (+310 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `CHANGELOG.md` (+10 -0) 📝 `open_terminal/main.py` (+300 -0) </details> ### 📄 Description ## Motivation I noticed a recurring failure pattern when an LLM agent wants to ADD a new section to a file: it expresses the intent as a `replace_file_content` call with a made-up `target` (usually the heading it wants to add) and a `replacement` that starts with that same text. Since the "target" never existed in the file, this just fails with a generic `"Target string not found"`, and the model often concludes the file was truncated and goes into an unproductive re-read loop rather than realizing it needed a different operation. ## What this adds Three companion operations to `replace_file_content`, for ADDING rather than replacing: - **`POST /files/insert_after`** -- insert content on a new line immediately after the first line matching an anchor substring. `allow_multiple` to insert after every match instead of erroring on ambiguity. - **`POST /files/append_to_section`** -- find a markdown heading by substring, append content at the end of that section (immediately before the next heading at equal-or-shallower depth, or EOF). Correctly skips past deeper sub-headings within the section. - **`POST /files/append`** -- append at end of file, handling missing trailing newlines on both sides. Also hardens `replace_file_content` itself to catch the pattern directly: when `target` is identical to the first non-empty line of `replacement`, it refuses with a specific error naming the three ops above, instead of the generic "not found" message. I know adding new endpoints is a bigger ask than a small bug fix -- happy to adjust naming/shape, split this into smaller pieces, or drop the defensive-check part if you'd rather keep `replace_file_content` untouched. Also totally understand if this is outside what you want in scope; no worries either way. ## Testing No test harness exists in this repo currently, so verified end-to-end against the real running server: - Defensive check correctly refuses and leaves the file untouched, with the new-ops hint in the error message. - `insert_after` inserts correctly after the matched anchor. - `append_to_section` appends before the next heading, correctly skipping past a sub-heading's body. - `append` appends with correct newline handling. - Regression: a legitimate replace where `target != replacement`'s first line is unaffected by the new check. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

2026-10-18 21:11:10 +00:00

No labels

bug

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

open-webui/open-terminal#141

No description provided.

Rows
Columns