security: sandbox shell-tool working_directory to jupyter_root

[pjdoland]

Summary

The two shell-execution tools surfaced to the LLM agent (`run_command_in_embedded_terminal` and `run_command_in_jupyter_terminal`) accepted a `working_directory` argument and passed it through unsanitized. An LLM tool call with `working_directory='/etc'`, `'../../..'`, or a workspace symlink to an outside directory would land a real shell outside the Jupyter workspace. The sibling `execute_command` tool already routed `working_directory` through the existing `_get_safe_path()` gate; these two were the only outliers.

This PR closes that gap.

Solution

Both tools now apply the same gate:

1. `work_dir = _get_safe_path(working_directory)` resolves the path and raises if it escapes `jupyter_root_dir`.
2. Reject with the same error string `execute_command` already emits when the directory doesn't exist or isn't a directory.
3. Forward the sandboxed absolute path to `subprocess.Popen(cwd=...)` or to the JupyterLab UI command that opens a terminal.

Error-string wording and shape match the sibling for consistency in the chat UX. No public API changes; the tool schema docstrings already steered the LLM toward relative paths.

Testing

Thirteen new pytest cases in `tests/test_builtin_toolset_cwd_sandbox.py`. For each rejection, the test asserts that `subprocess.Popen` (or the UI-command spy) was never called, so a true regression flunks the test rather than silently allowing the escape.

Coverage:

• Absolute path outside the workspace
• Relative `../../..` traversal
• Symlink inside the workspace pointing outside (the most realistic bypass, since `Path.resolve()` chases symlinks)
• Combined-prefix traversal (`valid-subdir/../../..`) to pin that `resolve()` collapses `..` before the containment check
• Null byte in path
• Nonexistent directory
• File instead of directory
• Positive case: relative subdirectory
• Positive case: `.` meaning the root
• Same set repeated for the Jupyter-terminal sibling

Suite-wide checks pass: `pytest tests/` (734 passing, +13 new), `jlpm tsc --noEmit`, `jlpm lint:check`, `jlpm jest` (154 passing).

Verified the new tests fail without the fix by reverting `built_in_toolsets.py` and re-running; all six relevant rejection tests flunk as expected, then pass once the fix is reapplied.

Risks / follow-ups

• Behavior change: a user workflow that legitimately relied on an absolute path outside the workspace will now see a tool error and the LLM will re-issue with a relative path. The tool description in the schema ("relative to jupyter_root_dir, default is root") already advertised the relative-path contract, so this aligns runtime behavior with the documented contract.
• Symlinks: workspace-internal symlinks pointing outside (e.g. a user-created shortcut to `~/code`) are also rejected. This matches the existing behavior of `execute_command` so the two tools stay consistent.
• The `_get_safe_path` error message echoes the resolved `jupyter_root_dir` absolute path back to the LLM. This is consistent with the sibling and is acceptable for a per-user tool; not worth altering here.

[mbektas]

thanks @pjdoland . do we need this also for the same tool in claude.py https://github.com/notebook-intelligence/notebook-intelligence/blob/main/notebook_intelligence/claude.py#L1071

[pjdoland]

Good catch, yes. The Claude-mode tool at claude.py:1071 has the same gap. It hands working_directory to the frontend notebook-intelligence:run-command-in-terminal command (src/index.ts:1185), which passes the value straight to terminal:create-new as cwd. Nothing on either side resolves it against jupyter_root_dir, so an LLM call with working_directory='/etc', a ../../.. traversal, or a workspace symlink pointing outside opens a terminal there and runs the command.

I'll send a follow-up PR after this one lands that:

1. Lifts _get_safe_path out of built_in_toolsets.py and into util.py next to get_jupyter_root_dir(), so the Claude-mode @tool registrations can share the same gate without an import cycle.
2. Applies the gate inside run_command_in_jupyter_terminal in claude.py.
3. Mirrors the pytest coverage from this PR for the Claude-mode path (absolute escape, .. traversal, symlink, null byte, nonexistent dir, file-not-dir, plus the positive cases).

While I'm in there I'll also take a look at open-file-in-jupyter-ui (claude.py:1089), which forwards file_path to docmanager:open. Lower-severity since it's a read path that goes through JupyterLab's contents service, but worth confirming the service rejects out-of-root paths before assuming it's safe.

Happy to bundle the audit findings into the same follow-up PR, or split them, whichever you prefer.