"classic" confinement for snap "tessl"


  • name: tessl
  • description: Command line developer utility that integrates with AI agents.
  • snapcraft: tessl-snap/snap/snapcraft.yaml at main · popey/tessl-snap · GitHub
  • upstream: ‘PRIVATE’
  • upstream-relation: I work on the DevRel team at Tessl.
  • supported-category: IDE
  • reasoning: tessl is a command line tool (and mcp server) that integrates with all existing agentic AI tools (codex, claude, gemini etc), and leverages numerous other tools (git, npm, python), and auto-configures projects for coding agents it can locate on the filesystem.

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.

Note that snappy-debug can be used to identify possible required interfaces. See https://snapcraft.io/docs/debug-snaps for more information.

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

Hello @popey!

Given that granting classic confinement is a highly sensitive matter, could you please expand a bit more on the specific issues you have faced when trying to get strict confinement to work, and which integral tessl functionalities require classic.

Thank you!

Ok, there’s a bunch.

Tessl is a tool that developers use alongside their coding agent. As such the tessl CLI requires very broad access, due to the variety of coding agents that are in use and supported by the tool.

Locating binaries

Tessl looks for binaries on the filesystem such as cursor, codex, and claude, in order to configure a software repo for use of tessl with them. Tessl is unable to find those binaries when strictly confined, so presumes they don’t exist, and will not do one of the primary “init” steps of configuring itself in the repo.

e.g:

$ tessl init
✓ Authenticated as alan@tessl.io

⚠ Creating empty tessl.json...

Detected 6 agent(s) needing setup: Claude Code, Cursor, Gemini cli, Codex, GitHub Copilot CLI, GitHub Copilot for VS Code

✔ Created MCP client configuration for 6 agent(s):
- Claude Code: .mcp.json
- Cursor: .cursor/mcp.json
- Gemini cli: .gemini/settings.json
- Codex: .codex/config.toml
- GitHub Copilot CLI: .vscode/mcp.json
- GitHub Copilot for VS Code: .vscode/mcp.json

✓ Init complete!

That entire section in the middle fails when strictly confined because tessl is unable to find any of those binaries.

Manipulating global configuration

Beyond detecting the binaries, tessl init and tessl install can write configuration files into the home directories of those agents:

  • ~/.claude/CLAUDE.md, ~/.claude/commands/tessl/, ~/.claude/skills/tessl__*
  • ~/.cursor/commands/, ~/.cursor/skills/
  • ~/.gemini/commands/, ~/.gemini/skills/
  • ~/.codex/commands/, ~/.codex/skills/
  • ~/.openhands/agent_settings.json
  • ~/.tessl - tessl’s own global configuration

Spawning external agent processes

tessl run spawns the agent binaries directly (e.g. spawn(‘claude’, …), spawn(‘codex’, …)). Even if confinement allowed detecting them, executing them is separately blocked.

Source access

tessl init, tessl install, and related commands write files into the user’s current working directory; wherever their project lives. Because that can be any path on the filesystem (e.g. ~/Documents/myproject/, /srv/code/, etc.), strict confinement’s filesystem isolation breaks this entirely. The snap can only write to its own $SNAP_USER_DATA path.

Agent log harvesting

tessl agent-logs sync reads agent session logs from ~/.claude/projects/ (Claude Code JSONL transcripts) and ~/.cursor/chats/ (Cursor SQLite database transcripts). Strict confinement blocks all of these reads.


All of the above breaks in strict confinement. We cannot control where source code lives, nor where all the agents stash their config and chat logs, but need access to those locations in order to do what tessl does.

Hey @popey

Thanks for the thoughtful explanation.

  • Regarding the technical reasons, I believe the only potentially supported reason is “Spawning external agent processes”. I believe everything else can be achieved with a combination of personal-files, home and removable-media within the usual constrains. Regarding “Spawning external agent processes”, the usual recommendation is to stage the dependent software in the snap. However, this is possibly a not suitable pattern in this case.
  • I don’t believe tessl clearly fit in the IDEs category. I think it will need an override from an architect in order to proceed.
  • If the request is finally to be granted, the only way to go through the publisher vetting will be the Verified accounts process, as the upstream repository is private.

@pedronis what are your thoughts here?

1 Like