Repository navigation
[Bug]: BaseSandboxFilesystem.edit fails when replaceAll=false because the generated Python command contains literal \\n sequences` #2571
Description
Describe the bug**
BaseSandboxFilesystem.edit(..., replaceAll=false) fails before reading or modifying the target file. The generated python3 -c program contains literal \\n character sequences instead of actual newline characters. On a POSIX shell, \\n inside a double-quoted argument is passed to Python unchanged, so Python raises a SyntaxError.
This affects the default single-replacement path used by the edit_file tool. The file is left unchanged.
The bug is present in AgentScope-Java 2.0.0 and is still present on main at commit 9b77823678b4ae919f7c14bc10fb7560879979d7 (2.0.1-SNAPSHOT).
To Reproduce
-
Use a sandbox-backed filesystem whose
executeimplementation runs commands through a POSIX shell and providespython3. -
Create a file such as
/tmp/example.txtcontainingold. -
Invoke the filesystem edit operation with
replaceAll=false, for example through the tool:edit_file({"path":"/tmp/example.txt","old_string":"old","new_string":"new"}) -
Observe that the operation fails with a Python syntax error and
/tmp/example.txtis unchanged.
The generated command starts with:
python3 -c "import sys, os, base64, json\npayload = ..."
A minimal shell-level reproduction is:
python3 -c "import sys, os, base64, json\npayload = {}"Expected behavior
The first occurrence of old_string should be replaced with new_string, and the edit operation should return a successful EditResult.
Error messages
Error editing file '/tmp/example.txt': unexpected server response: File "<string>", line 1
import sys, os, base64, json\npayload = json.loads(...)
^
SyntaxError: unexpected character after line continuation character
Environment (please complete the following information):
- AgentScope-Java Version: 2.0.0; also reproducible from
mainat9b77823678b4ae919f7c14bc10fb7560879979d7(2.0.1-SNAPSHOT) - Java Version: OpenJDK 21.0.12
- OS: macOS 26.3.2 arm64 host; POSIX sandbox shell with Python 3
Additional context
The command is constructed in:
agentscope-harness/src/main/java/io/agentscope/harness/agent/filesystem/sandbox/BaseSandboxFilesystem.java
The Python source lines are currently joined using Java string fragments ending in \\n, for example:
"python3 -c \"import sys, os, base64, json\\n"This produces a backslash followed by n at runtime, not a line feed. POSIX shells do not translate \\n inside double quotes. Python then interprets the backslash as a line-continuation character and rejects the following n.
The returned process exit code is also not checked before parsing stdout. Because the syntax-error output contains neither the expected "error" nor "count" JSON field, it is reported as unexpected server response, which hides the actual command-execution failure.
Possible fixes:
- Use actual newline characters (
\nin the Java source) when building the Python program, or pass the Python program through a quoted heredoc and pass the Base64 payload as an argument. - Check a non-zero execution exit code before parsing the expected JSON response.
- Add a real-shell integration test for
edit(..., replaceAll=false)that verifies the file contents.
Activity
aiyili commentedon Sep 21, 2026
Hi, I'd like to work on this issue. I've prepared a fix that:
python3 -cprogram with a Java text block so its statements are separated by real line feeds — inside a POSIX double-quoted string the literal two-characterSyntaxError(verified against a realsh+ python3: the old command fails, the fixed command performs the replacement).unexpected server response.edit(..., replaceAll=false)(single replacement, multiple-occurrence refusal, replaceAll).PR coming shortly.
fix(harness): 沙箱 edit 生成的 python3 -c 程序含字面 \n 序列,replaceAll=false 时必然…
oss-maintainer commentedon Sep 21, 2026
Issue Evaluation
Category:
bug| Status: Confirmed (checked againstmain@c0d03ccea)The reported defect is real and still present. Code-engine verification:
python3 -cprogram uses literal\n(backslash +n) instead of real newlinesagentscope-harness/src/main/java/io/agentscope/harness/agent/filesystem/sandbox/BaseSandboxFilesystem.java:258-281replaceAll=falsepath ofedit_fileFilesystemTool.java:166defaultsreplaceAll=false. Additional finding: thereplaceAll=truebranch builds the exact same command shape, so both branches are affected, not only the default oneSyntaxErroris raised while Python parses-c, beforesys.stdin.read()/open()mainWhy it fails: the Java source terminates each Python statement with
\\n, which at runtime is the two-character literal\n. Inside shell double quotes a backslash beforenis not an escape, so Python receives the whole program as one physical line and aborts at parse time.Blast radius:
SandboxBackedFilesystemandSharedSandboxFilesystemextendBaseSandboxFilesystemand do not overrideedit(...), so every sandbox-backed filesystem shares the defect — theedit_filetool path is broken there. Severity: high.Test gap:
BaseSandboxFilesystemTesthas noeditcoverage, andFilesystemToolTestmocks the filesystem layer, so the generated command string is never executed or asserted. Any fix should pin the command construction (real line feeds present, base64 heredoc payload intact) so this cannot regress.On fix work: two community PRs already target this issue — #2573 and #3226. To avoid duplicate competing work, no automated fix proposal will be generated from this evaluation; the maintainer review queue on those PRs is where this should land. Reviewers may want the extra
replaceAll=truefinding and the regression-test point above.Automated evaluation by github-manager (oss-maintainer)
fix(harness): 沙箱 edit 生成的 python3 -c 程序含字面 \n 序列,replaceAll=false 时必然…
fix(harness): sandbox edit generated python3 -c program with literal
Merge upstream/main into fix/sandbox-edit-native-python
fix(harness): fail-closed move/delete and surrogate-safe tail clamp (a…