Finds the registered project carrying the huskies source tree, runs
`cargo build --release` inside its container (dedicated
CARGO_TARGET_DIR=target/sled-release so container builds stop
clobbering host target/release), then atomically publishes the binary
to ~/.huskies/artifacts/ with a .hash sidecar for convergence checks.
Full fleet redeploy is now chat-only: `release` then `upgrade all` —
no laptop access needed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019fHdm92yjvguPi2LiXfLB9
- `upgrade all` sweeps every registered sled in sequence, streaming
per-sled phase markers and reporting a summary.
- Binary source is now the gateway's own artifact store via
host.docker.internal (was: unresolvable `gateway` hostname serving
the gateway's macOS binary to Linux sleds — would have bricked them).
- Sleds with active claude processes are skipped, never killed.
- After reconnect, /api/version git_hash is compared against the
published artifact's .hash sidecar; divergence is reported loudly.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019fHdm92yjvguPi2LiXfLB9
GET /api/artifacts/:filename with filename validation (no path
components, no dotfiles). Sleds only ever download binaries from their
own gateway; this endpoint is where the gateway serves them from,
replacing the current_exe()-based /api/huskies-binary which serves the
gateway's own (macOS) binary — wrong platform for Linux sleds.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019fHdm92yjvguPi2LiXfLB9
/opt/huskies/bin/huskies (chowned to the huskies user) with a symlink
from /usr/local/bin/huskies. Atomic replace needs write permission on
the directory for the tmp-write + rename, which root-owned
/usr/local/bin can't provide to the server process.
resolve_target_path() now prefers /opt/huskies/bin/huskies over
current_exe(), which can point at a stale location (e.g.
/workspace/target/release/huskies after a historical in-container
rebuild) that the entrypoint would never launch after a restart.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019fHdm92yjvguPi2LiXfLB9
CARGO_MANIFEST_DIR is baked at image build time as /app/server, but
project containers (Dockerfile.base) don't copy /app — the source is
bind-mounted at /workspace instead. Fall back to project_root when
the compile-time path doesn't exist.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Two issues that surfaced when story 1 ran in the adopted huskies-server
sled:
1. Dockerfile.base: the base image had no nodejs / claude CLI, so every
coder agent spawn in an adopted project sled failed with
`Unable to spawn claude: No viable candidates found in PATH`. Install
nodejs + @anthropic-ai/claude-code in the base image so every sled
built from it can spawn agents out of the box.
2. worktree/create.rs::install_pre_commit_hook: `git config --worktree`
requires `extensions.worktreeConfig = true` to be set on the repo
config; without it, every worktree creation logged a noisy
`Pre-commit hook install failed` warning. Enable the extension
idempotently before the per-worktree hooks-path set so the hook
install succeeds cleanly.
After this, rebuild huskies-project-base and recreate any adopted
project containers to pick up the CLI.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Story 1130 added HUSKIES_HOST=0.0.0.0 so the server INSIDE a project
container binds to all interfaces, but the host-side `docker -p`
mapping was still `127.0.0.1:{port}:3001` and `127.0.0.1:{ssh_port}:22`
— reachable from the docker host only, blocking remote MCP clients
and out-of-host SSH onto the project container.
Switch host-side mapping to 0.0.0.0 for both the MCP and SSH ports so
project containers spawned via `new project` are reachable from
anywhere that can route to the docker host. Existing containers
created before this commit retain their localhost-only mapping and
need to be recreated to pick up the change.
Add a regression test asserting both -p arguments use 0.0.0.0 and
reject any 127.0.0.1 restriction in the mapping.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>