3 Commits

Include renames

Author	SHA1	Message	Date
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