(#2377) fix(shell): sanitize terminal-facing output and harden path checks

[vjanelle]

Harden terminal-facing output in the exec tool and logger by escaping control and format characters before they reach the console or LLM-facing output. Refine exec workspace path validation so normalized relative paths inside the working directory remain allowed while real escapes are blocked.

Type of change

• 🐞 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 📖 Documentation update
• ⚡ Code refactoring (no functional changes, no api changes)

🤖 AI Code Generation

• 🤖 Fully AI-generated (100% AI, 0% Human)
• 🛠️ Mostly AI-generated (AI draft, Human verified/modified)
• 👨‍💻 Mostly Human-written (Human lead, AI assisted or none)

N/A

• Reference URL: N/A

• Reasoning: Raw ANSI escape sequences and Unicode bidi overrides should not be able to alter operator terminal state. The previous workspace guard also rejected any path containing ../ even when the normalized path still resolved inside the working directory.

• Hardware: PC

• OS: Linux

• Model/Provider: GPT-5.2 / OpenAI codex

• Channels: internal terminal / exec tool usage

Click to view Logs/Screenshots

• Added tests for ANSI and bidi escaping in terminal-facing output
• Added tests for allowing normalized in-workspace relative traversal
• Added tests for blocking relative traversal that escapes the working directory

• My code/docs follow the style of this project.
• I have performed a self-review of my own changes.
• I have updated the documentation accordingly.

[CLAassistant]

All committers have signed the CLA.

[yinwm]

Great work on hardening the terminal output and path validation! The overall approach is solid. I have a few items that need attention before this can be merged:

Blocking:

1. Merge conflict + Linter failure — Please rebase onto latest main and fix the lint errors.
2. C1 control characters gap — EscapeControlChars doesn't catch C1 control characters (U+0080–U+009F). In UTF-8 these are encoded as 0xC2 0x80–0xC2 0x9F. While most modern terminals use 7-bit CSI, some still interpret 8-bit C1 codes (e.g., 0x9B = CSI). Consider adding r >= 0x80 && r <= 0x9f to the escape condition.

Please verify:
3. Logger Component color in TTY mode — FormatPrepare injects ANSI color codes into the Component field (\x1b[33m...\x1b[0m), but formatFieldValue now calls EscapeControlChars on all field values. If zerolog's ConsoleWriter calls FormatFieldValue for the Component part, the injected color codes will be escaped to literal text. Could you verify this doesn't break TTY color output?

Non-blocking suggestions:
4. Consider adding dedicated unit tests for EscapeControlChars in pkg/termutil/ covering C0, C1, DEL, bidi, zero-width chars, and edge cases.
5. Shell variable expansion (\/../path) can theoretically bypass the path traversal check since filepath.Abs treats \ as a literal directory name. This is low-risk given the AI agent context, but worth documenting as a known limitation.

[yinwm]

Additional finding from deeper review:

Timeout path bypasses EscapeControlChars — In runSync, when a command times out (context.DeadlineExceeded), the function returns early at line 443-448 with the raw output embedded in the message, skipping the EscapeControlChars call at line 470. This means a command that intentionally stalls past the timeout can inject raw ANSI escape sequences and bidi overrides into both ForLLM and ForUser.

The fix is straightforward: apply EscapeControlChars to output before the timeout check, or apply it to msg before the early return.

[vjanelle]

@yinwm any opinions about ZWJ and complex emoji?