Repository navigation
[Filesystem] add append tools #1208
Description
Is your feature request related to a problem? Please describe.
Currently, if I want to append a new line of text to an existing .txt file using this tool, there only have wirte_file now.
Describe the solution you'd like
I would like a new tool to be added, named append_file or append_wirte_file. This function should perform the following actions:
Accept two main arguments: the path to the target text file and the string content to be appended. Write the provided string content to the end of the file.
Crucially, automatically add a newline character (\n or the appropriate OS-specific newline) after the appended content. This ensures that each call to this function adds the content on a new line, making subsequent appends also start on a fresh line.
Handle the closing of the file automatically and safely.
Describe alternatives you've considered
None.
Additional context
None.
Activity
X1pheR commentedon Oct 13, 2026
The current #2816 head 9bb47c9 resolves the earlier missing-file creation problem: append uses O_APPEND without O_CREAT/O_TRUNC, validates regular-file/device/inode identity, and has a distinct exclusive create-or-append operation. I am retaining the existing issue/PR rather than submitting duplicate append code.
One additional downstream contract remains outside that PR: a text-only append operation refuses NUL-containing/invalid UTF-8 targets, syncs the handle, reads back exactly the appended bytes at physical EOF, and returns bounded bytes_appended/post_size/SHA-256 tail metadata without rereading unrelated file contents into the response. If another append races after the write, this strict tail check can fail even though bytes were written; it is a postcondition receipt, not an atomic transaction or rollback guarantee.
This is deliberately narrower than a general append_file. Would maintainers accept an opt-in verified-text append contract, or prefer a documented extension hook so it remains an external adapter? The existing #2816 should not be held up or represented as covering these extra guarantees. Under the maintainer-only PR policy, I am requesting direction here instead of opening another PR. No upstream merge/release or full equivalence is claimed.
cliffhall commentedon Oct 19, 2026
Triage: Priority Low (total 4)
Board: Servers V2 (#43), Status
Incoming, awaiting maintainer review (no milestone yet). Part of the backlog triage in #4875.cliffhall commentedon Oct 20, 2026
Prior work, from the PR backlog triage (#4877). These outside pull requests addressed this issue against the pre-refactor code:
They are being closed as part of the backlog triage in #4875, since the repository now takes issues rather than outside PRs and their diffs predate the v2 refactor. They stay readable and serve as prototypes for the fix here. Thank you to their authors.
agn-7 commentedon Oct 20, 2026
Thanks @cliffhall for keeping this feature tracked and crediting my prior work. I'd like to continue contributing to the filesystem server through the maintainers' workflow.
One clarification for the record: the latest PR #2816 head, 9bb47c9, was already updated to SDK v2 and retargeted to
v2/mainon October 12. That revision passed the complete local gate, all 377 runnable filesystem tests and coverage on Node 22, Inspector checks in both protocol eras, and an LLM-client smoke test. A fresh merge simulation againstv2/mainatf18beb7also completed without conflicts. Please keep this latest revision in mind when describing the prototype's compatibility with the refactor; the initial PR predates it, but the current implementation includes that migration.For the issue-based implementation workflow, the prototype's scope is:
append_file: append the supplied text at physical EOF of an existing regular file, without creating, truncating or replacing it; preserve the existing file identity and upstream validation boundary.create_or_append_file: create exclusively when absent, or use the same checked append path when present, including when another process wins the creation race.Could we scope a concrete next step for me to carry this feature forward under maintainer supervision, including any refinements and validation you want? I'm interested in ongoing filesystem work, and would appreciate guidance on the appropriate contributor channel or arrangement. If the implementation or regression tests are carried forward, please preserve the attribution to that work in the eventual change.