#264 Extension push: allow shipping executable host helpers (bin/mudroom blocker)

Problem

swamp extension push enforces a hard allowlist on additionalFiles:

File extension "" is not allowed. Allowed: .ts, .json, .md, .yaml, .yml, .txt

This blocks any extension that needs to ship an executable host-side helper — a bash wrapper, a native binary, or any file whose entire purpose is "be on the user's PATH (or behind a shell function) and run".

The allowlist also rejects .sh, so even renaming the script doesn't help.

Concrete use case

@hivemq/mudroom / @bixu/mudroom is a swamp model that runs Claude Code in an apple/container sandbox. The model methods orchestrate the container, but the user-facing entry point is a host-side bash wrapper (bin/mudroom) that:

• looks up the workspace name from cwd,
• ensures a per-workspace model instance exists in swamp,
• pulls the Claude credential out of the host Keychain,
• exec's into the running container, and
• dispatches subcommands (claude, shell, up, down, destroy, status).

The model also bundles a mudroom-setup skill that installs a shell function pointing at this binary. The skill assumes the binary is shipped inside the pulled extension at <repo>/.swamp/pulled-extensions/@<collective>/mudroom/files/bin/mudroom.

Today that path is empty, because additionalFiles: [bin/mudroom] is rejected at push time. The only working install path is therefore "clone the source repo and use the dev checkout", which is the opposite of canonical.

This is not a hypothetical — multiple extensions in this space (any wrapper around an apple/container, docker, k8s, or local-tool workflow) want to ship a thin host shim that invokes swamp model method run under the hood.

Why this matters

• The published-extension experience is the canonical one. A model that can only be installed via dev checkout cannot be advertised on swamp.club as "pull and use".
• The host-shim pattern is exactly what the recently-filed Lab #262 (shell-shim manifest support) is asking swamp to make first-class. Without a way to actually ship the shim binary, that feature has no payload.
• The allowlist seems aimed at preventing extensions from smuggling non-source artifacts in — but it currently has the side effect of blocking the legitimate "ship a small executable helper" use case entirely.

Proposed solutions

Listed in order of increasing scope:

1. Allowlist additions — at minimum, accept .sh. Files arriving without an executable bit can be invoked via bash <path> in the consuming extension's setup skill, which is what most host-shim use cases actually want.

2. Manifest opt-in for an additionalBinaries list — a new manifest field that:

   • accepts paths regardless of extension,
   • preserves the executable bit on extract,
   • surfaces clearly in the publish summary and on the swamp.club extension page (so users see "this extension ships executable host helpers" before pulling),
   • integrates with Lab #262 (shell-shim declarations can reference these binaries by name).

3. First-class host-shim packaging (full version of #2) — declared binaries are auto-symlinked into a swamp-managed bin/ directory under the pulled-extensions root, with a documented stable path that setup skills can reference unconditionally. This is the answer to "the skill keeps having to write the absolute path of the binary into the user's shell config — what if the binary path were a stable, swamp-managed constant instead?"

Workaround today

Option 2 is the cheapest immediate fix and would unblock @*/mudroom without forcing every extension that wants this pattern to refactor every host-side responsibility into model methods.

Related

• Lab #262 — shell-shim declarations in the manifest (depends on this).