wslKinds had none of these CLIs, so each was set up only on Windows.
Each now has a place-aware constructor (codebuddyIn, clineIn, geminiIn,
atomcodeIn, gooseIn, reasonixIn). It writes the distro's own config with
the gateway as the distro reaches it (mirrored or NAT) and the key it
takes from there. A distro reads none of Windows' variables
(CODEBUDDY_CONFIG_DIR, CLINE_DIR, APPDATA...). Kinds are found by their
folder or their command. Gemini CLI is found by its command alone,
because Antigravity keeps ~/.gemini too. Goose is found by its folder
alone, because a goose command can be pressly's. Reasonix also needs a
native version (new wslKind.accept). Gemini CLI also counts a .env that
names an old address with magpie's key as magpie's own. Before this, a
WSL restart that moved the distro's address made it read "custom", and
picking the model again stashed magpie's old address as the user's.
Verified:
- On the Windows test box (WSL2 magpie-desktop, NAT), with a sandboxed
nogui magpie.exe (own USERPROFILE/APPDATA, port 3441), real CodeBuddy
Code 2.161.4, Gemini CLI 0.63.0 and Cline CLI 3.0.68 were installed in
the distro. `magpie ls` listed each as "· WSL magpie-desktop".
Picking relay/glm-4.6 wrote ~/.codebuddy/models.json, ~/.gemini/.env +
settings.json and ~/.cline/data/settings/providers.json in the distro
at http://172.17.32.1:3441, and wrote nothing in the sandbox home's
agent folders. The installs were removed afterwards.
- Not tried for real: AtomCode, Goose and Reasonix in a distro, and a
chat request from a WSL CLI through the gateway.
- Tests: gofmt; go vet ./...; -race on internal/agent; the full
`go test -tags nogui ./...`; GOOS=windows and GOOS=linux builds.
TestWSLProbeFindsMoreAgents and the rest of TestWSLMore* panic with
"no WSL agent codebuddy" on the old wsl.go.
TestWSLGeminiAddressMoved fails ("auth custom") without the gemini
routed change.
yetone
6f65ffb5ff