fix(sandbox): block .. escapes when shell destinations do not exist

[cursor]

Bug and impact

With sandbox workspace_only enabled (the documented default), a shell command whose destination does not exist yet was allowed if the string started with the workspace path. That lets the agent copy the SQLite store (sessions, memories, cron) out of the workspace, or write files elsewhere the process can write:

cp /home/user/.shellclaw/memory.db /home/user/.shellclaw/../../tmp/stolen.db

sandbox_exec only unshares namespaces and chdirs; it does not pivot_root. The allowlist is the filesystem gate.

Root cause

allowlist_path_is_under_workspace used realpath when the path existed, then fell back to a lexical prefix check. realpath fails for a missing file, so workspace/../../tmp/newfile matched the workspace prefix and was allowed. Existing destinations still went through realpath and were denied.

The file tool already walks to the first existing ancestor. The shell allowlist did not.

Fix

When realpath fails, walk parents with dirname until an existing directory resolves, then apply the workspace prefix check to that resolved ancestor. New files inside the workspace stay allowed.

Validation

• Compiled tests/test_allowlist.c against the patched allowlist (this environment has no libcurl, so make test_allowlist cannot link the default -lcurl).
• test_allowlist: all tests passed, including a new case that previously failed: workspace/../../tmp/sc_al_stolen_<pid> is blocked, while workspace/brand_new.txt is still allowed.