4 Commits

Include renames

Author	SHA1	Message	Date
DevvynandClaude Opus 5	4830e662f9	refactor(cli-registry): make CLI backends data instead of per-mode branching ... Every run mode is now a `CliEntry` in `src/config/cli-registry/` — discovery (search dirs, version + identity probes), the launch argv template, env handling, the `capabilities` flags that replace per-CLI branching, and the `overlays` that back the remote/docker pane commands. Code that used to ask "which CLI is this?" reads the entry instead. Behaviour is unchanged. `test/cli-registry-spawn-golden.test.ts` pins every spawn command as a literal string, captured from the hand-written builders before they were deleted, and `test/location-overlay-commands.test.ts` does the same for all 20 remote and in-container pane commands. Config can never contain shell text: an entry declares typed argv tokens, literals are validated against a safe-word pattern at LOAD time (a bad literal rejects the whole entry — a silently dropped `--no-approve` is not cosmetic), and values resolve through patterns NAMED in code, so a user `clis.json` cannot widen its own validation. `~/.codeman/clis.json` overrides any entry, read-only in this release. OMP is included as a registry entry rather than a tenth hand-written builder, so `buildOmpCommand()`, the omp availability pre-flight, the omp arm of `buildPathExport()` and the omp entries in the truecolor/NO_COLOR, alt-screen and doctor ladders all drop out. Guard rails: - `test/cli-registry-no-id-branching.test.ts` fails the build if per-CLI-id branching reappears outside `stock.ts`, in any of its four shapes (`===`, `!==`, `switch`/`case`, `includes`) — an `===`-only version would miss the negated forms, which is how 36 of them survived an earlier pass. Every allowlisted branch carries its reason. - `external`, `hooks` and `altScreen` stay three INDEPENDENT capabilities; deriving one from another shipped the `until=stop`-hangs-on-shell bug. - `param` is two namespaces. `launch.params` keys, `configSetenv.fromParam` and `privilegedParams[].param` all name a LAUNCH param; the legacy `<Mode>Config` wire field is separate, bridged only by `legacyConfigAliases`. Getting `privilegedParams[].param` wrong is SILENT — it is the multi-user bypass clamp's only handle on a CLI's privilege switch, and a wrong name clamps nothing with no error and no failing test — so `schema.ts` rejects an entry naming a param it never declared. - Registry data resolves AT CALL TIME (`sessionModeSchema()`, `allowedEnvPrefixes()`, `dependencyRegistry()`, the resolvers' `searchDirs` thunks). A module-level const freezes at first import, so a CLI enabled while the server ran moved the run menu but not that surface. - Six fields are annotated DECLARED-FOR-LATER and read by nothing (`shortBadge`, `accent`, `capabilities.echo`/`wheelForward`/ `keyboardAccessory`/`maxFrameBytes`): all frontend behaviour, transcribed rather than measured. A test pins the list so it cannot quietly grow. Three user-visible changes, all deliberate and named: - `probeDockerCliVersion()` derives the in-container binary from the registry rather than assuming it equals the mode name (`antigravity` runs `agy`). - The remote CLI version probe now covers grok and deepseek, which the hardcoded map it replaces omitted while its own comment said the rule was "every mode except shell". - `codeman doctor`'s CLI rows are generated from the entries, so Claude's install hint is the install command rather than a docs URL, five CLIs gain hints they never had, and the row order follows the catalog. Also hardened along the way: `sessionModeSchema()` is bounded at 24 chars (matching the `cliId` pattern) before its failure message quotes the value back, and `deepMerge` skips `__proto__`/`constructor`/`prototype` when reading the hand-editable `clis.json`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WQkoi1cNegqVwZHgzx5SbJ	2026-09-02 08:26:45 +08:00
Codeman maintainer	3f8c8e99d1	feat(grok): add Grok Build (xAI) as a seventh CLI run mode ... SessionMode gains 'grok', a first-class backend alongside Claude Code, shell, OpenCode, Codex, Gemini, Antigravity and Pi: its own PTY, tmux session, charcoal tab identity ('gk' badge), welcome button, run-mode entry, cron agentType, Docker and remote-SSH command defaults, and clone-repo Brain option. Flag surface verified live against grok 1.0.5. Grok mixes two existing shapes and the wiring follows from that: - Codex-shaped on permissions: the bypass switch is GrokConfig.alwaysApprove (--always-approve, grok's bypassPermissions mode; config-level deny rules still apply on top). The Run button sends it true, like runAntigravity(), and clampExternalCliBypassForOwner() puts grok in the only-if-sent branch: a bare grok spawn is grok's own ask-mode default, which is already safe, so only a sent config needs the flag forced off. Cron needs nothing for the same reason. - OpenCode-shaped on rendering: grok is a fullscreen alternate-screen TUI with mouse support, so it stays OUT of isAltScreenStripMode() and lands on the narrow tmux-attach strip and the 'buffer' local-echo fallthrough (unmeasured against an authenticated composer; documented fallback is the 'off' branch). - Pi-shaped on resolution: 'grok' has npm squatters (@vibe-kit/grok-cli also installs a grok bin), so grok-cli-resolver.ts version-probes every candidate (grok --version, killSignal SIGKILL, VITEST-gated) and GET /api/grok/status surfaces path AND version; GROK_VERSION_REGEX is shared with the dependency registry so doctor and run mode cannot drift. Env allowlist gains GROK_* plus the XAI_* vendor namespace (XAI_API_KEY is grok's documented headless auth var), the same narrow-vendor reasoning as GOOGLE_* for gemini. Resume is id-regexed on purpose: grok's own --resume also matches session titles, which are arbitrary user strings that must never reach the bash -c spawn line. Docker: grok is not on npm, so the agent image installs it in its own step (xAI's installer has no --dir override; the binary is copied to /usr/local/bin and root's ~/.grok dropped in the same layer), and credentials are seeded per-file (auth.json, config.toml, pager.toml; the dir also holds sessions/, memory/ and the ~160MB binary). Remote SSH routes through the login-shell wrapper like the other agent CLIs. Verified end to end on an isolated CODEMAN_INSTANCE with grok 1.0.5 installed: /api/grok/status resolves and reports the probed version, quick-start spawns a pane whose command line ends in 'grok --always-approve', the real TUI renders (OAuth device screen on an unauthenticated box), and grokConfig round-trips through state.json. Docs: docs/grok-integration.md (user guide) + docs/grok-integration-plan.md (decisions, verification record, follow-ups). Tests: test/grok-mode.test.ts, test/grok-cli-resolver.test.ts, plus extended clamp/system-routes/render-index-html/run-mode-ui/mobile-overview/ local-echo-gating coverage. npm test (the CI gate) green: 5910 tests. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-23 08:39:03 +02:00
Codeman maintainer	61251c0b94	fix(cli-resolvers): negative-result caching, SIGKILL on probes, restored VITEST hermeticity, wired not-found diagnostics ... Post-merge follow-ups for PR #329 (shared CLI executable resolution): - Negative-cache resolution misses with a doubling backoff (1min -> 5min cap, cliResolveRetryDelayMs, mirroring claudeVersionRetryDelayMs): the shared resolver cached success only, so a missing CLI re-ran the whole chain - ending in a synchronous interactive login-shell spawn bounded by the 5s EXEC_TIMEOUT_MS - on every /api/<cli>/status request and Run attempt, stalling the event loop each time, forever. Success still caches for the process lifetime, so an installed CLI is picked up within minutes without a restart. Tests drive the backoff via an injectable clock (createCliExecutableResolver `now` option, threaded through the createPiResolverForTest / createAntigravityResolverForTest wrappers). - Pass killSignal: 'SIGKILL' on the resolver's login-shell spawn and on the pi/claude --version probes: execFileSync's timeout only SENDS the kill signal and then keeps waiting for the child to exit, and interactive bash ignores SIGTERM, so a login shell stuck in a blocking .bash_profile survived the timeout and blocked the server permanently. - Restore test hermeticity (PR #329 deleted pi's VITEST guards, and one test pinned the deletion): under vitest the production resolver host now replaces un-injected IO primitives with inert stubs - no real PATH scanning, no login-shell spawns - and probePiVersion never executes a `pi` candidate again (`pi` is a generic binary name, so route tests hitting /api/pi/status executed whatever binary the machine carried). Tests opt in through the runCommand/isExecutableFile injection hooks or allowRealIoUnderVitest for real-filesystem fixtures. The deletion-pinning test is replaced by behavioral pins, including a real-executable fixture in the new test/pi-cli-resolver.test.ts that fails loudly if the pi gate is ever removed again. - Wire the six get*NotFoundMessage() exports (previously dead) into their intended call sites: the createSession throws in tmux-manager and the availability gates on POST /api/sessions and POST /api/quick-start in session-routes, replacing a third hardcoded copy of the text. A not-found error now names where resolution looked (server PATH, login shell, checked directories). npm run knip no longer reports any unused export from the resolver modules. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-21 02:37:58 +02:00
Aamer Akhter	fef903df98	fix(cli-resolvers): find CLIs installed via nvm/Homebrew when running as a service ... A CLI installed by nvm, Homebrew or a user-level npm prefix lives on a PATH that only a login shell sets up. Codeman running under systemd or launchd does not get that PATH — launchd hands a job `/usr/bin:/bin:/usr/sbin:/sbin` — so every resolver reported the CLI as unavailable on installs where it is plainly there and works from a terminal. Each of the six resolvers had its own hand-rolled copy of the same PATH walk, so the fix is factored into one shared `createCliExecutableResolver()` with an explicit lookup order: the server process PATH, then common install directories in order, then an interactive login shell as the last resort. Only the last step spawns anything, and only when the cheap lookups have already missed. Also adds `formatCliNotFoundMessage()`, so a failure explains where it looked instead of just asserting the CLI is missing. Its diagnostics are bounded and control characters are flattened, so a not-found message cannot dump arbitrary environment data. Success is cached and failure is retried, so installing a CLI while the server is running is picked up without a restart. Net -103 lines across the six resolvers. Behaviour is unchanged wherever the CLI was already on the process PATH: that remains the first thing checked. Tests: 20 cases in test/cli-executable-resolver.test.ts covering the precedence order, login-shell-only resolution, the caching rule, unsafe-name rejection, and the bounded diagnostics.	2026-08-20 12:47:42 -04:00