Classic confinement request for MemStrata Coder

store-requests classic-confinement
1

name: memstrata-coder

description: MemStrata Coder is a local developer tool that maintains a compact, current map of user-selected source repositories and exposes that map to coding agents through IDE, MCP, and terminal integrations. It watches Git working trees, runs a loopback-only daemon and dashboard, and configures supported IDE/CLI integrations only at the user’s explicit request.

snapcraft: https://github.com/yadu9989/memstrata-coder/blob/bac7f543bd04be1c36c14cca68e3cf7e3e72e279/snap/snapcraft.yaml

upstream: https://github.com/yadu9989/memstrata-coder

upstream-relation: Called It Inc. is the upstream author, owner, and Snap Store publisher of MemStrata Coder.

supported-category: IDEs and tools for local, non-root user driven configuration of/switching to development workspaces/environments.

reasoning: I understand that strict confinement is preferred. We evaluated the existing home, removable-media, personal-files, and portal-based options. They cannot provide the required behavior because MemStrata Coder must:

  • read and watch arbitrary repositories explicitly selected by the user, including repositories outside $HOME;
  • follow repository moves and work with the user’s existing Git executable;
  • configure supported IDE and terminal integrations in their normal host configuration locations after explicit user consent;
  • invoke user-selected development commands and IDE CLIs in the host environment; and
  • preserve the host toolchain’s paths, credentials, and environment rather than replacing it with a separate sandboxed toolchain.

The repository and tool paths are user-defined and cannot be enumerated in advance. Strict confinement also cannot provide the necessary host command execution and workspace/IDE integration semantics. Classic is not requested to avoid packaging dependencies: the Python runtime and dependencies are included in the snap.

Security boundaries:

  • The service binds only to 127.0.0.1; it does not expose a LAN listener.
  • Project discovery and indexing are local. Repository contents are not uploaded by the discovery/indexing feature.
  • Startup is disabled by default and requires a separate user opt-in.
  • Tool configuration and project registration require explicit user actions or consented onboarding choices.
  • The application runs as the invoking non-root user and does not call sudo or pkexec.
  • The snap is not a third-party installer and does not install other snaps, native packages, AppImages, or Flatpaks.

Validation evidence:

The exact 0.6.5 amd64 snap was built from commit bac7f543bd04be1c36c14cca68e3cf7e3e72e279 using Snapcraft 9.0.1. It was installed locally with --dangerous --classic, reported version 0.6.5 and product profile coder, executed its normal CLI help path successfully, and was then removed. SHA-256: 957ae3abcbc980e8208e4eeeffa077429acdd23662894dfd78f7076fa13020ff.

We request classic-confinement approval for the memstrata-coder snap ID before releasing this revision to a Store channel.

2

This request has been added to the queue for review by the @reviewers team.

3

Hey @yadu9991

I would like to point out that listed github repository, https://github.com/yadu9989/memstrata-coder, is not accessible. Could you please first clarify if this is intentional (e.g. the project is intended to be closed source)?

4

Hi Jorge, yes this is intentional. MemStrata Coder is proprietary, closed-source commercial software, so the upstream GitHub repository is private.

The product itself is publicly installable from PyPI at https://pypi.org/project/memstrata-coder/ using python -m pip install memstrata-coder, and users receive six months of free use after sign-in and activation.

The classic-confinement request is needed for the host IDE, terminal, MCP, user-selected repository, and local development-tool integrations described above. If the review team needs source or build access for review, we can provide it privately through Canonical’s preferred reviewer channel. Please let me know the appropriate mechanism.

Thank you.

5

Hey @yadu9991

Thanks for the information!

Taking a closer look at the request, I’m not entirely sure that these are valid technical reasons for classic confinement.

read and watch arbitrary repositories explicitly selected by the user, including repositories outside $HOME;

This falls under the unsupported reason access to arbitrary files on the system due to developer/user inertia as defined in the Reviewing classic confinement snaps - Snap documentation

follow repository moves and work with the user’s existing Git executable;

Also falls under the unsupported reason dependent software only available on host (ship in instead snap (eg, stage-packages, build from source))

configure supported IDE and terminal integrations in their normal host configuration locations after explicit user consent;

This can possibly be achieved via personal-files interface, we can discuss about the concrete locations needed.

invoke user-selected development commands and IDE CLIs in the host environment; and

This is not possible to be achieved with strict confinement. This is intentionally not possible as this likely enables a confinement escape in most common scenarios. I believe this reason alone is not enough to justify the use of classic confinement. Could you please share more details about the typical use cases for this feature?

Thanks!

6

Hi Jorge, thank you. We reviewed the current implementation against your feedback and should narrow the original wording rather than imply that arbitrary paths or an unbundled Git dependency alone justify classic confinement.

The normal use case is a developer keeping their existing editor and terminal agents while MemStrata coordinates the current project context:

  1. The developer enables the shell/IDE integration, then opens or changes into an existing project. The shell hook identifies the Git working-tree root and calls memstrata-coder project add <root> to register it with the local service.
  2. The developer opts into supported tool configuration. The application adds named MemStrata endpoint/MCP entries for clients such as Continue, Codex and Grok, preserving backups of managed configuration. The developer still launches and authenticates those tools themselves.
  3. Those clients retrieve current repository context through MemStrata’s local MCP/harness endpoints. Edits made by the editor or agent are detected by the watcher so subsequent context requests use the updated source state. Build/test commands are run by the user’s editor/agent in that user’s development environment, not by a general-purpose command-execution endpoint in MemStrata.

The concrete host commands MemStrata itself currently invokes are narrower: Git root discovery in the consented shell hook; the installed VS Code CLI for extension installation/verification (code --install-extension / code --list-extensions); and systemctl --user for the existing optional user-service lifecycle. It does not need root access and these features are not a claim that arbitrary host command execution is intrinsically sufficient for classic approval.

The principal user configuration locations include the supported shell profile, ~/.continue/, ~/.codex/config.toml, ~/.grok/config.toml, ~/.cursor/mcp.json, and the optional user systemd unit. We accept your point that individual configuration paths can potentially be handled with personal-files; we can supply the complete reviewed integration and path list.

Given this more precise scope, would the application qualify under the developer-workspace/environment-tool category, or should we redesign the Snap around strict interfaces and a Snap-managed service, with any unsupported host integration explicitly left manual? We do not want to base the request on an unsupported rationale. Please let us know the acceptable route and the interfaces you would want evaluated.

The source repository remains private intentionally. No classic-confinement approval or new Store-channel release is being claimed while this review is outstanding. Thank you.

7

Hey @yadu9991

Thanks for your thoughtful reply!

Given this more precise scope, would the application qualify under the developer-workspace/environment-tool category, or should we redesign the Snap around strict interfaces and a Snap-managed service, with any unsupported host integration explicitly left manual?

According to the described functionality, I believe that strict confinement + Snap-managed service is the right approach here. Also worth noting that snaps using classic confinement cannot be installed on Ubuntu Core devices.

If I’m not missing anything, the unsupported host integration will include:

  • Registering the shell/IDE integration
  • VS Code CLI for extension installation/verification

This is the sort of tasks that I think it makes sense to let the user to handle in most cases, because:

  • allowing the snap to register a shell extension enables a trivial confinement escape and it is listed as unsupported reason for classic-confinement as per as per https://snapcraft.io/docs/reference/administration/reviewing-classic-confinement-snaps/.
  • third party installer (like using code --install-extension) is intentionally not supported under strict confinement and it is also listed as unsupported reason for classic-confinement.

The principal user configuration locations include the supported shell profile, ~/.continue/, ~/.codex/config.toml, ~/.grok/config.toml, ~/.cursor/mcp.json, and the optional user systemd unit. We accept your point that individual configuration paths can potentially be handled with personal-files; we can supply the complete reviewed integration and path list.

If I understood it correctly, the main point of this is to register the MemStrada Coder mcp server, so the agents know how to reach it. I believe it would possibly more interesting to register them in the project configuration for each project added to MemStrada Coder, rather than using the global configuration. This has two advantages

  • You won’t need access to the global configuration files, access to the project repository would be enough
  • Only projects registered on MemStrada Coder will see the mcp server. This means that projects that are not registered will not use extra context (and tokens) for no reason.

You could possibly add this per-project configuration step to memstrata-coder project add <root> so it will still be seamless for the user.

Thanks