| dev.containers.metadata |
{"id":"wraptool","version":"1.2.1","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 installs no harness binary. The binary comes from the host's shared harness pool `runtime/` tree (built by `wraptool harness install <name>`), which you declare as a read-only bind mount in devcontainer.json. `wraptool up` requires that declaration and refuses, printing the exact entry to add, when it is missing or not read-only; `wraptool init devcontainer` scaffolds it for new projects. Without the declaration there is no binary on PATH, however the container was started. Declare BOTH pool mounts, 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 Windows-specific step is setting HOME at all, since only %USERPROFILE% is set by default there: `setx HOME %USERPROFILE%`, see docs/platform-windows.qmd). The `harness` option only selects which MCP config shape `connect` writes. The `:0` major (per-image provisioning, with `provision`/`version` options) is UNSUPPORTED: its published artifact stays available, but nothing ships for it and `wraptool up` never falls back to the binary it installs. Pin `:1` explicitly rather than `:latest`.","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` requires it and refuses, printing the exact entry to add, when it is missing or not read-only (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"} |
