Feature request: Sandbox mode for the MCP server (confine tools to one workspace)

Description

Hello @yamadashy — been a while!

Quick context: this comes through ZenitechCS's fork — my company's been leaning on repomix for an internal project and we'd like to send a couple of pieces back upstream. Thanks for the tool, it's been doing a lot of heavy lifting for us.

Motivation

When repomix runs as an MCP server, its file tools can read anywhere on the host. If you want to hand the server to an AI agent that should only ever touch one project, it should be restricted to a sandbox.

This would be especially helpful for integrators — anyone embedding repomix's MCP server into their own app or a hosted/multi-tenant service, where it runs on a shared server and the agent shouldn't see anything beyond the project it's working on.

Proposed feature

A --sandbox [dir] flag (used with --mcp) that locks the server to a single workspace directory, defaulting to the working dir:

repomix --mcp --sandbox                # confine to the working directory
repomix --mcp --sandbox path/to/proj   # confine to a specific directory

• input paths are resolved relative to the workspace root — absolute / ~ / .. / drive / UNC are refused;
• everything the agent sees is virtualized to root-relative paths — tool results and error text alike — so the real absolute paths and the host's filesystem layout are never exposed;
• only the workspace-scoped read-only tools stay on (pack_codebase, read_repomix_output, grep_repomix_output, file_system_read_file, file_system_read_directory); remote packing, skill generation and attaching external outputs are disabled;
• tool descriptions and instructions branch on the mode, so normal (non-sandbox) behavior is unchanged.

Two layers, two PRs

I've split this so each stays easy to review:

1. the pure-software path guard above — portable, no new deps — up now in https://github.com/yamadashy/repomix/pull/1753
2. an OS-kernel enforcement layer on top (Landlock / Seatbelt / AppContainer, via FFI) so the confinement holds even for subprocesses and raw syscalls — It's already implemented, I'll open the next PR if this looks good to you.