| dev.containers.metadata |
{"id":"wraptool","version":"1.2.0","name":"wraptool","description":"Wire a dev container's AI coding harness to a host-side wraptool MCP server. Wiring-only major (see design/harness/unified-harness-pool.md §12): this feature no longer installs the harness binary. The binary comes from the host's shared harness pool `runtime/` tree (built by `wraptool harness install <name>`), which must be DECLARED as a read-only mount in devcontainer.json — the devcontainer CLI's `--mount` flag has no read-only field at all, so `wraptool up` cannot inject this mount itself; it only VERIFIES the declaration and prints the exact entry to add when it's missing. `wraptool init devcontainer` scaffolds the declaration for new projects. Existing configs (including anything scaffolded against the old `:0` provisioning major) must add BOTH pool mounts to declare it themselves, e.g.: { \"mounts\": [ \"source=${localEnv:HOME}/.local/share/wraptool/harness-pool/home,target=/home/wraptool-harness,type=bind\", \"source=${localEnv:HOME}/.local/share/wraptool/harness-pool/runtime,target=/opt/wraptool-harness/runtime,type=bind,readonly\" ] } — rewrite the source for your OS per §12.3: on macOS the two sources are '${localEnv:HOME}/Library/Application Support/wraptool/harness-pool/home' and '${localEnv:HOME}/Library/Application Support/wraptool/harness-pool/runtime'; on Windows they are '${localEnv:HOME}/AppData/Local/wraptool/harness-pool/home' and '.../runtime' — the `${localEnv:HOME}` rewrite works there too (per internal/paths, %LOCALAPPDATA% is itself %USERPROFILE%\\AppData\\Local, just a different relative path than the Linux/macOS defaults); the Windows-specific step is setting HOME at all, since only %USERPROFILE% is set by default there (`setx HOME %USERPROFILE%`, see docs/platform-windows.qmd). This applies whether or not you use `wraptool up`: without the declaration there is no binary on PATH regardless of how the container was started. The `harness` option now only selects which MCP config shape `connect` writes. The old provisioning major (`:0`) remains published for existing configs that still set `provision`/`version`, but is deprecated — new setups should pin this major explicitly (`:1`, wiring-only) rather than `:latest`, which now resolves here; `:0` stays the address for the legacy per-image provisioning behavior.","documentationURL":"https://forge.snamellit.com/pti/wraptool/src/branch/main/features/src/wraptool","options":{"harness":{"type":"string","enum":["claude","opencode","pi","agy","omp"],"default":"claude","description":"Which harness this feature wires — the MCP config shape connect writes. No longer selects an installer: the binary is not provisioned by this feature (see the top-level description)."},"connect":{"type":"boolean","default":true,"description":"Write the MCP client config that wires the harness to the host wraptool (postCreate). Set false to wire it yourself (e.g. host-side `wraptool init`)."},"port":{"type":"string","proposals":["8717"],"default":"8717","description":"Host wraptool port, used by connect when the URL is auto-detected."},"url":{"type":"string","default":"","description":"Explicit wraptool base URL for connect (e.g. http://172.18.0.1:8717). Empty = auto-detect the host as the container's default-route gateway."}},"//":"HOME is pinned to the shared-pool mount target (/home/wraptool-harness — a dedicated user-space home, not a system /opt path). PATH gains the pool runtime's bin dir, appended (never prepended — pool tools must not shadow project tools, mirroring §12.1's rule). DISABLE_AUTOUPDATER=1 stops Claude Code from updating itself: the pool binary is version-locked, and its self-update would `npm install -g` an unlocked, unquarantined copy into any writable npm prefix in the image (e.g. the node feature's), which then shadows the pool binary because the pool dir is appended to PATH. All three are feature invariants, not gated by a toggle: devcontainer features can't conditionalize containerEnv on an option value, and containerEnv is the layer that actually survives `devcontainer exec` (remoteEnv is reverted by its user-env probe). A Feature's containerEnv is emitted verbatim into the image's Dockerfile ENV — plain `$VAR`/`${VAR}` only, NOT the devcontainer-CLI's `containerEnv:`-prefixed substitution form (that form is remoteEnv/mounts/devcontainer.json scope only; BuildKit hard-errors on the colon modifier inside an ENV value), so PATH here reads the base image's own build-time PATH via `${PATH}`. Caveat shared with other official features: a base image whose config env has no PATH at all expands `${PATH}` to empty, leaving a leading ':' (implicitly puts CWD on PATH) — accepted. install.sh only creates the HOME dir (so it is valid even without a mount) and stages connect.sh; it installs no packages and makes no network access. `wraptool up` bind-mounts the host pool's home/ ($XDG_DATA_HOME/wraptool/harness-pool/home, per-developer XDG data) onto HOME automatically, but the read-only runtime/ mount onto the PATH target must be DECLARED in devcontainer.json (the devcontainer CLI's --mount has no read-only field): `wraptool init devcontainer` scaffolds the declaration, and `wraptool up` only verifies it is present and correctly read-only, printing the exact entry to add when it is not (design/harness/unified-harness-pool.md §12.2/§12.3, examples/devcontainer).","containerEnv":{"HOME":"/home/wraptool-harness","PATH":"${PATH}:/opt/wraptool-harness/runtime/bin","DISABLE_AUTOUPDATER":"1"},"postCreateCommand":"/usr/local/share/wraptool/connect.sh"} |
