-
name: local-shell-mcp
-
description: local-shell-mcp is an open-source MCP control plane that allows AI coding agents, under user control, to work with the local shell, filesystem, browser automation, terminals, and remote development machines.
-
snapcraft: The initial Snap packages the official standalone executable released at: Release v3.2.0 · fwerkor/local-shell-mcp · GitHub
-
upstream: GitHub - fwerkor/local-shell-mcp: Enables LLM to use a cli environment. · GitHub
-
upstream-relation: I am the upstream project owner and publisher.
-
supported-category: development tools / tools for local, non-root user driven development workflows
-
reasoning: Classic confinement is required because local-shell-mcp is explicitly a development and automation tool whose core purpose is to execute arbitrary user-authorized shell commands and existing host executables, and to access user-selected workspaces and filesystem paths.The set of commands and paths cannot be enumerated ahead of time. Typical workflows require access to tools installed by the user such as git, Python, Node.js, compilers, package managers, Docker/Podman, SSH, editors, and arbitrary project-specific executables. Strict confinement would fundamentally change the semantics of the product: the agent would see the snap sandbox rather than the user’s actual development environment and would be unable to invoke many host-installed tools or access arbitrary user-selected working directories. The application does not silently perform privileged system administration. Shell/filesystem operations are initiated through the MCP interface on behalf of the user and remain subject to local-shell-mcp’s own policy and authorization controls.
I understand that strict confinement is generally preferred, but existing Snap interfaces are insufficient for this application’s core functionality.
I understand that strict confinement is generally preferred over classic.
I’ve tried the existing interfaces to make the snap to work under strict confinement.