#381 swamp CLI commands fail silently or hang when invoked from git worktrees via SWAMP_REPO_DIR

Description

When an agentic pipeline creates a git worktree (e.g. git worktree add trees/my-feature) and invokes swamp commands from inside that worktree using SWAMP_REPO_DIR pointing to the main checkout, several commands fail or hang:

• swamp model method run hangs indefinitely (0% CPU, active TCP connection to nothing)
• swamp extension fmt <path> errors with YAML parse failures when the extension source file exists only in the worktree (not in the main repo's .swamp/ cache)
• swamp model create and swamp model type describe fail because the extension bundle isn't available in the worktree's context

Environment

• swamp 20260516.045246.0-sha.e6eda98d
• macOS Darwin 25.3.0, ARM64
• Git worktrees created by an automated pipeline that runs git worktree add trees/<session-id> from the main repo

Architecture

Our setup uses a single swamp repo (~/git/tooling-repo) as the control plane for multiple target projects. We don't initialize swamp in the target project repos yet — the tooling and workflows aren't battle-tested enough to introduce to the wider team. The same goes for the prompt/config management approach: a secondary repo holds project-specific configs (e.g. adw.yml) that get synced into target repos via a script. Until the patterns are proven, the swamp files and workflow stay isolated in the tooling repo.

The pipeline works like this:

1. A prompt/config repo contains project-specific configs (e.g. adw.yml) that get synced into target project repos via a sync script
2. The agentic pipeline runs from the tooling repo and creates git worktrees for isolation: git worktree add trees/<session-id>
3. Build agents inside the worktree invoke swamp commands via SWAMP_REPO_DIR=~/git/tooling-repo swamp model method run ...
4. Extension model source files (.ts) are created by the build agent inside the worktree at extensions/models/my_model.ts

Steps to Reproduce

1. Initialize swamp in a repo: swamp init
2. Create a local extension model at extensions/models/example.ts
3. Run swamp extension install (registers the model type)
4. Create a git worktree: git worktree add trees/test-branch
5. From the worktree, try: SWAMP_REPO_DIR=<main-repo-path> swamp model method run example invoke --json
6. Also try: swamp extension fmt extensions/models/example.ts from inside the worktree

Expected: Commands work the same as from the main checkout since SWAMP_REPO_DIR points to the initialized repo.

Actual:

• swamp model method run hangs indefinitely — the Deno runtime starts but never completes
• swamp extension fmt fails with SyntaxError: Cannot read document when it tries to parse the .ts file as YAML, or when the extension source only exists in the worktree (not in .swamp/ cache)

Impact

This blocks any pipeline that uses git worktrees for branch isolation (a common pattern for automated code generation pipelines that need to work on feature branches without dirtying the main checkout). We had to remove all swamp CLI invocations from our pipeline's acceptance criteria and defer them to post-merge manual steps.

Possible Root Causes

1. Lock contention — swamp model method run acquires a per-model lock. If the worktree's SWAMP_REPO_DIR resolves to a different filesystem path than expected, the lock may never be acquired or released.
2. Extension bundle cache miss — .swamp/ stores compiled extension bundles. When the source .ts file exists in the worktree but the bundle was compiled from the main checkout, the paths don't match and the runtime can't find the bundle.
3. swamp extension fmt path resolution — The command expects a manifest.yaml or directory path, but when given a .ts file path from a worktree, it may resolve relative to the wrong root.

Workaround

Don't run swamp CLI commands from git worktrees. Only invoke them from the main checkout after changes are merged or cherry-picked back. For automated pipelines, mark swamp-dependent verification steps as post-merge tasks.

Question

Would initializing swamp directly in the target project repo (instead of using a separate control-plane repo with SWAMP_REPO_DIR) resolve the worktree issue? Or does the .swamp/ cache have the same path-resolution problem regardless of where swamp init was run?