#8846: fix(tools): block LLM writes to hooks directories

## Summary Block write/edit operations to hooks directories to prevent code injection via prompt injection attacks. ## The Problem Workspace hooks are loaded from `<workspace>/hooks/*/handler.ts` with highest precedence—they override bundled and managed hooks. If an attacker achieves prompt injection, they can instruct the LLM to write a malicious hook handler that will execute on gateway restart with full privileges. This is a persistent backdoor vulnerability that survives across sessions and gateway restarts, allowing credential theft, message interception, and arbitrary code execution (CWE-94: Code Injection). ## Changes - `src/agents/restricted-paths.ts`: New module that validates file paths against restricted directory patterns - `src/agents/restricted-paths.test.ts`: Comprehensive tests for restricted path validation - `src/agents/pi-tools.read.ts`: Added `createRestrictedWriteTool()` and `createRestrictedEditTool()` functions - `src/agents/pi-tools.ts`: Updated to use restricted write/edit tools for non-sandboxed operations ## Test Plan - [x] `pnpm build && pnpm check && pnpm test` passes - [x] New test suite `describe('VULN-201: workspace hook write restriction')` validates: - Blocks writes to `hooks/` directory within workspace - Blocks writes to nested paths under hooks directory - Blocks edits to files under hooks directory - Blocks writes to CONFIG_DIR hooks directory (`~/.openclaw/hooks/`) - Allows writes to non-hooks directories - Allows writes to directories with similar names (webhook, hooks-backup) - Blocks path traversal attempts that resolve to hooks ## Related - [CWE-94: Improper Control of Generation of Code ('Code Injection')](https://cwe.mitre.org/data/definitions/94.html) - Internal audit ref: VULN-201 --- *Built with [bitsec-ai](https://github.com/bitsec-ai). AI-assisted: Yes. Testing: fully tested (test written before fix). Code reviewed and understood.* <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR introduces a restricted-path guard for LLM-powered `write`/`edit` tools to prevent prompt-injection persistence via workspace/managed hooks (VULN-201). It adds `src/agents/restricted-paths.ts` to normalize/resolve paths and reject writes/edits targeting hook directories, wires the guard into non-sandboxed tool creation via `createRestrictedWriteTool()` / `createRestrictedEditTool()` in `src/agents/pi-tools.read.ts`, and updates `src/agents/pi-tools.ts` to use these restricted tools. A new vitest suite (`src/agents/restricted-paths.test.ts`) exercises blocking of workspace hooks, nested paths, edits, CONFIG_DIR hooks, and basic allow cases. <h3>Confidence Score: 3/5</h3> - Generally improves security posture, but has a potentially over-broad restriction and a potentially flaky env-dependent test. - The core mitigation (wrapping write/edit with a restricted path guard) is straightforward and well-tested for the intended hook locations, but the current implementation appears to block any absolute path containing a `hooks` segment (overreach that can break legitimate workflows). Additionally, the CONFIG_DIR test may be order-dependent due to module-level caching of `CONFIG_DIR`. - src/agents/restricted-paths.ts; src/agents/restricted-paths.test.ts <!-- greptile_other_comments_section --> <!-- /greptile_comment -->