Feature: secure skills management

[thecodeassassin]

We are exploring adding a feature for skill management using

https://github.com/vercel-labs/skills

Open questions:

• How can we make this as secure as possible without introducing supply-chain-attacks?
• Should we verify any skills before adding them to workspaces?

[matt-roz]

There's a real supply-chain problem here that's worth spelling out before we talk about what ExitBox should do about it.

Claude Code users who install marketplace skills end up with auto-allow entries like this in their settings:

"permissions": {
  "allow": [
    "Skill(superpowers:*)",
  ]
}

Combined with the marketplace source config:

"extraKnownMarketplaces": {
  "superpowers-dev": {
    "source": { "source": "github", "repo": "obra/superpowers" }
  }
}

This means Claude Code will automatically fetch and execute skills from that GitHub repo with no confirmation prompt; the user already blanket-allowed them. If that repo gets taken over, a compromised maintainer force-pushes, or someone social-engineers transfer of the repo name, every session silently loads attacker-controlled instructions. Pair that with "enableAllProjectMcpServers": true and you've got arbitrary tool execution with zero user interaction.

This isn't something ExitBox should try to police, unless you really want to. It's a host-side Claude Code configuration choice and users are free to make it. But we should document the risk and provide a safer workflow.

What ExitBox should do

Best practice: vendor your skills locally. Use skills.sh (npx skills add <repo> --copy) to hard-copy skill files into your filesystem rather than relying on live symlinks to cloned repos that can change upstream. Once they're local files under your control, you can audit them and they won't mutate behind your back.

From there, skills naturally fall into trust tiers:

In-repo skills (.claude/skills/ etc.): already trusted. They're part of your codebase, they go through your PR review, they're version-controlled. ExitBox doesn't need to do anything special here, they're in the workspace mount and the agent picks them up.

User-global skills (~/.claude/skills/): these live outside the project and could've been modified by anything. When ExitBox detects skills being loaded from outside the workspace, a tmux prompt asking to confirm loading would be nice; same UX we already have for domain-allow and vault-access popups. Something like:

[ExitBox] Load external skill?

  Source: ~/.claude/skills/frontend-design/SKILL.md

  [y/N]:

And lastly, Explicit CLI whitelisting for power users who keep a curated skills directory:

exitbox run claude --skill-dir ~/my-skills
exitbox run claude --skill /path/to/SKILL.md

These would mount the paths into the container and mark them as trusted (skip the prompt). Similar to how --include-dir works but with skill-specific semantics.

It would be nice if there is somehow a way to block runtime marketplace fetching by default. If someone wants marketplace skills, they should install them on the host first (as described above), then let ExitBox mount them in. Alternatively a flag --dangerously-allow-marketplace-skills (no short-hand) is a good alternative to "allow" users to resolve marketplaces from their configs.

What ExitBox should NOT do

• Inspect or filter Claude's settings.json; it's not really our config to mess with
• Build our own skill registry (each user has their own requirements)
• Try to verify skill integrity at runtime: that's the job of the install/audit step on the host

The philosophy stays the same as the rest of ExitBox's security model: sandbox the runtime, trust what the user explicitly provides, prompt for everything else.