Skip to content

fix(cli): pin HERMES_KANBAN_BOARD at chat boot to stop subprocess board drift#20094

Closed
0xDevNinja wants to merge 1 commit intoNousResearch:mainfrom
0xDevNinja:fix/20074-pin-kanban-board-env
Closed

fix(cli): pin HERMES_KANBAN_BOARD at chat boot to stop subprocess board drift#20094
0xDevNinja wants to merge 1 commit intoNousResearch:mainfrom
0xDevNinja:fix/20074-pin-kanban-board-env

Conversation

@0xDevNinja
Copy link
Copy Markdown
Contributor

What does this PR do?

In cmd_chat, pin the resolved kanban board into HERMES_KANBAN_BOARD once at boot when the env var isn't already set. Without this, in-process kanban_* tools and shelled-out hermes kanban … subprocesses resolve the board on different paths — env-var pin if present, otherwise the global <root>/kanban/current file. A concurrent hermes kanban boards switch from another session can flip that file mid-turn, so the same chat ends up routing tool calls to board A while its shell calls hit board B, surfacing as phantom "no such task" errors when an orchestrator immediately tries to harness kanban show <id> after kanban_create.

This mirrors the behaviour the dispatcher already has for spawned workers (hermes_cli/kanban_db.py:2622-2623) — pin the board into the child env so every code path resolves the same DB. Idempotent and a no-op when the caller has already exported the env (e.g. dispatcher-spawned worker, ad-hoc shell pin).

Related Issue

Fixes #20074

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 🔒 Security fix
  • 📝 Documentation update
  • ✅ Tests (adding or improving test coverage)
  • ♻️ Refactor (no behavior change)
  • 🎯 New skill (bundled or hub)

Changes Made

  • hermes_cli/main.py: add _pin_kanban_board_env() helper and call it from cmd_chat after the existing env-flag block, before forking to TUI vs CLI.
  • tests/hermes_cli/test_pin_kanban_board_env.py: cover the three branches — pin when unset, no-op when already set, swallow get_current_board() failures (boot must never crash because the kanban dir is missing or unreadable).

How to Test

  1. harness kanban boards switch space (Terminal 1)
  2. harness -p space-orchestrator chat (Terminal 1) — leave it sitting at the prompt.
  3. harness kanban boards switch harness-facet (Terminal 2, concurrent).
  4. Back in Terminal 1's chat, ask the orchestrator to kanban_create a task and then immediately shell harness kanban show <id>. Before the fix, the shell-out lands on harness-facet and reports "no such task". After the fix, both calls resolve to space because HERMES_KANBAN_BOARD=space was pinned at chat boot.
  5. Unit tests: pytest tests/hermes_cli/test_pin_kanban_board_env.py -v (3/3 pass).

Checklist

Code

  • I've read the Contributing Guide
  • My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
  • I searched for existing PRs to make sure this isn't a duplicate
  • My PR contains only changes related to this fix/feature (no unrelated commits)
  • I've run pytest tests/ -q and all tests pass (15 pre-existing failures in gateway/web_server/bedrock unrelated to this change; full hermes_cli suite green except those)
  • I've added tests for my changes (required for bug fixes, strongly encouraged for features)
  • I've tested on my platform: macOS 14.2 (Darwin 23.2.0)

Documentation & Housekeeping

  • I've updated relevant documentation (README, docs/, docstrings) — N/A (helper docstring covers the rationale; no user-facing surface added)
  • I've updated cli-config.yaml.example if I added/changed config keys — N/A
  • I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
  • I've considered cross-platform impact (Windows, macOS) per the compatibility guide — env-pin is platform-agnostic; mirrors existing dispatcher behaviour.
  • I've updated tool descriptions/schemas if I changed tool behavior — N/A

…rd drift

Without an explicit pin, in-process kanban tools and shelled-out
`hermes kanban …` subprocesses resolve the active board on different
paths: the env var when set, otherwise the global `<root>/kanban/current`
file. When a concurrent session toggles the current-board pointer
mid-turn, the same chat ends up routing tool calls to board A while its
shell calls hit board B, surfacing as phantom "no such task" errors.

Pin the resolved board into env once at `cmd_chat` boot when
HERMES_KANBAN_BOARD isn't already set. Mirrors what the dispatcher does
for spawned workers (kanban_db.py:2622-2623). Idempotent and a no-op
when the env is already pinned by the caller.

Closes NousResearch#20074
@alt-glitch alt-glitch added type/bug Something isn't working comp/cli CLI entry point, hermes_cli/, setup wizard P3 Low — cosmetic, nice to have labels May 5, 2026
@teknium1
Copy link
Copy Markdown
Contributor

teknium1 commented May 5, 2026

Merged via PR #20186 (commit f8a6db6). Your commit was cherry-picked onto current main with your authorship preserved in git log.

One small follow-up landed alongside: your test file used monkeypatch.delenv("HERMES_KANBAN_BOARD") for cleanup, but the helper under test writes to os.environ directly — monkeypatch only tracks its own mutations, so the "space" value survived teardown and broke 9 tests in TestSharedBoardPaths when run in the same suite (xdist hid it; serial run made it obvious). Added an autouse snapshot/restore fixture. Filed as a separate commit so your original is clean.

Thanks for the tight fix, clear repro, and the concrete suggestion on where to put the pin — made the salvage trivial.

#20186

@teknium1 teknium1 closed this May 5, 2026
@0xDevNinja
Copy link
Copy Markdown
Contributor Author

Appreciate the salvage and the fixture catch. monkeypatch.delenv vs a helper that writes os.environ directly is a sharp footgun — only undoes its own mutations, so anything the function-under-test sets stays set after teardown. Will reach for an autouse snapshot fixture by default whenever the code path mutates os.environ outside monkeypatch. Thanks for keeping the original commit clean.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/cli CLI entry point, hermes_cli/, setup wizard P3 Low — cosmetic, nice to have type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: harness kanban CLI invoked from agent session ignores active-board pin, races current file with concurrent boards switch

3 participants