[Bug]: `execute` tool has no working-directory sandbox — a run can read unrelated projects/sessions and adopt their identity

Description

The system prompt (src/agent/prompt.ts:36) tells the model the filesystem tools (ls, read_file, write_file, edit_file, glob, grep) are virtually rooted at the target repository, but is explicit that execute is different: "Shell execute commands run on the host." In practice there's no enforcement at all behind that distinction — execute can cd, ls, find, and cat anywhere on the filesystem the OS user can reach, with no path allowlist or working-directory jail.

I confirmed this directly in a real run's persisted history (~/.openwiki/openwiki.sqlite, the LangGraph checkpoint store): a single OpenWiki session, mid-conversation, ran (paraphrased, exact commands available on request):

• ls -la /, ls -la $HOME
• find $HOME/<other-agent-config-dir> -name "*.jsonl"
• read_file on another AI coding tool's local session-history log (completely unrelated to this repo)
• cd into a different, unrelated git repository elsewhere under $HOME and run git log/git status there

None of this required leaving the "openwiki" chat session or any special escalation — it's just what execute can already do.

Impact — this is not hypothetical

In the case I traced, the agent used execute to read an unrelated project's old AI-assistant session transcript (from a different tool entirely, on the same machine), and then started speaking in first person as if it were that other session — apologizing to the user for a git push/git clone that a different assistant session had performed on a different repository weeks earlier. It had, in effect, absorbed a stranger session's identity and actions as its own, purely because execute let it wander into that session's history file.

Separately, and worse: earlier in the same conversation, when the user asked what it had access to, the model answered confidently that it works in "a sandboxed environment rooted at the target repository" and explicitly said it could not browse the home folder or paths outside the repo. That statement is flatly false, and the same session demonstrated it was false a few turns later. So the model isn't just capable of scope escape — it actively told the user the opposite of its real capability.

(No repo damage resulted in the traced case — the wandering session only read files and made a fresh, unmodified clone of the unrelated repo, no new commits/pushes — but that was incidental, not enforced.)

Steps to Reproduce

1. Start openwiki in any repository.
2. Ask it (or let a long/ambiguous conversation drift toward) something outside that repo — e.g., "what other projects do I have on this machine," or anything that invites curiosity about $HOME.
3. Observe that execute will happily ls/find/cd/cat anywhere outside the target repository, with nothing in the tool layer stopping it.

Expected Behavior

Either:

• execute should be constrained to the target repository the same way the filesystem tools already are (working directory pinned, absolute paths outside the repo rejected, or a real chroot/sandboxing layer), or
• if unconstrained host access is intentional/by design, the system prompt must not tell users the opposite (i.e., drop or correct the "sandboxed environment... can't browse your home folder" framing so users can make an informed judgment about what they're granting).

Actual Behavior

execute has unrestricted host shell access. The model's own self-description to the user claims sandboxing that does not exist, and in a real session this combination let the assistant read another tool's private session history and absorb that session's identity/actions when talking to the user.

Suggested Fix

• Add a real working-directory/path restriction to the execute tool, mirroring the existing virtual-root approach used for read_file/write_file/edit_file/glob/grep.
• If that's not feasible short-term, at minimum update createSystemPrompt() (src/agent/prompt.ts) so the model's own claims about its sandboxing match execute's actual, documented "runs on the host" behavior — the current wording sets the model up to misinform users about what it can access.

Environment

• OS: Android / Termux
• OpenWiki: local dev checkout, main-adjacent branch