Summary

The write tool and exec heredocs both insert literal backslash-n (\n) instead of actual newline characters when the content contains escape sequences in string literals.

Environment

• OpenClaw v2026.5.28 (M4 uday_one)
• macOS Darwin 25.5.0 arm64
• Shell: zsh

Steps to Reproduce

Via write tool:

write(path="/tmp/test.py", content="lines = [\n    'line 1',\n    'line 2',\n]\n")

Result: file contains literal \n characters, not newlines. Python syntax error on execution.

Via exec heredoc:

cat > /tmp/test.py << 'EOF'
x = 'first line\n    second line'
EOF

Result: the \n inside the string literal is written as two characters (backslash + n), not a newline.

Expected Behaviour

\n in string content should be preserved as-is (a literal two-character sequence), which is the normal Python string escape. The file should be written byte-for-byte as provided.

Actual Behaviour

The \n sequences are being treated as line continuation characters by the shell, producing SyntaxError: unexpected character after line continuation character when the resulting file is run.

Impact

Blocks any workflow that writes multi-line Python files programmatically — e.g. patch scripts, generated code, config builders. Requires a base64 encode/decode workaround:

python3 -c "import base64; exec(base64.b64decode('<encoded>').decode())"

This works but is unnecessarily complex and opaque.

Workaround

Encode the entire script as base64 and decode+exec via python3 -c. Confirmed working.

Notes

• Affects write tool, exec with heredoc, and exec with -c flag
• Does NOT affect exec with actual newlines in the script body (multiline heredoc content is fine; the issue is specifically with backslash-n inside string literals within heredoc content)
• Building replacement strings as lists joined with chr(10) also avoids the issue