[Bug]: BaseSandboxFilesystem.edit fails when replaceAll=false because the generated Python command contains literal \\n sequences`

[HuJiShuang]

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

1. Use a sandbox-backed filesystem whose execute implementation runs commands through a POSIX shell and provides python3.

2. Create a file such as /tmp/example.txt containing old.

3. 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"})
   

4. Observe that the operation fails with a Python syntax error and /tmp/example.txt is 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 main at 9b77823678b4ae919f7c14bc10fb7560879979d7 (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:

1. Use actual newline characters (\n in 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.
2. Check a non-zero execution exit code before parsing the expected JSON response.
3. Add a real-shell integration test for edit(..., replaceAll=false) that verifies the file contents.