fix(tool): apply external_directory: deny to every literal path a bash command names

docs/docs/configure/permissions.md

@@ -204,6 +204,10 @@ When working near production systems. Blocks destructive operations entirely and
 }
 ```
 
+With `external_directory: "deny"`, the bash tool refuses any command whose literal text names a path outside the project (arguments and option values, programs run by path, redirections, assignment values, `cd`/`pushd` targets and literal `sh -c`/`eval` strings), resolved through symlinks and in the directory each command runs in. Directories you allow under `external_directory` keep working. A `"*": "deny"` also removes the default allow for skill directories and the CLI temp directory, so bundled skill scripts stored there are refused unless you allow those directories again.
+
+This is a guard rail, not a sandbox. It sees only literal command text: paths built at run time (`$HOME/x`, `$(pwd)/..`, globs) and files a program opens on its own (`python -c "open('/etc/hosts')"`, a script that writes to `/tmp`) are not checked. Use a container or VM when you need isolation.
+
 ### Per-Agent Lockdown
 
 Give each agent only the permissions it needs:

docs/docs/reference/security-faq.md

@@ -305,6 +305,7 @@ Altimate Code includes several layers of protection to keep the agent within you
 - **Path traversal blocking.** Paths containing `../` sequences that would escape the project are rejected with an "Access denied" error.
 - **Sensitive file protection.** Writing to credential files (`.env`, `.ssh/`, `.aws/`, private keys) triggers a confirmation prompt, even inside the project. See [below](#why-am-i-being-prompted-to-edit-env-files) for details.
 - **Bash command analysis.** The bash tool parses commands with tree-sitter to detect file operations (`rm`, `cp`, `mv`, etc.) targeting paths outside your project, and prompts for permission.
+- **Bash path guard under `external_directory: "deny"`.** With the default (`"ask"`) or `"allow"`, the bash tool checks only the file operations above. When `external_directory` is `"deny"` for `*`, it also refuses any command whose text names a path outside the project: arguments (including `--opt=/x`, `-o/x` and `key=/x` values), a program run by path, redirection targets, assignment values (`PY=/x`, `export PATH=/x:$PATH`), `for`/`[[ ]]`/`case` words, `cd`/`pushd` targets, and literal `sh -c '…'`/`eval "…"` strings. Each path is resolved in the directory its command runs in and through symlinks, so a symlink inside the project that points outside is caught. Directories allowed in `external_directory` (and the tool-output directory) stay usable. Under a `"*": "deny"` rule, skill and reference directories and the CLI temp directory lose their default allow unless you allow them again, so bundled skill scripts that live there are refused too. This is a guard rail over literal command text, not a sandbox: paths built at run time (`$HOME/x`, `$(pwd)/..`, globs, variables set outside the command), paths a program opens itself (`python -c "open('/etc/hosts')"`, a script that writes to `/tmp`), heredoc bodies and shells nested more than three levels deep are not seen.
 - **Non-git project safety.** For projects outside a git repository, the boundary is strictly the working directory (not the entire filesystem).
 
 These protections operate at the application level. For additional isolation, you can run Altimate Code inside a Docker container or VM.