Summary

Make cli.py survive on Windows when there is no Win32 console screen buffer attached to the process — the situation every hermes child of a Windows service / scheduled task / DETACHED_PROCESS parent finds itself in. Previously these processes died at the very first colored line, before AIAgent was even constructed.

The fix is a small wrapper around _pt_print(_PT_ANSI(text)) (_safe_pt_print()) that catches prompt_toolkit.output.win32.NoConsoleScreenBufferError and falls back to plain sys.stdout.write. Interactive-terminal behavior is byte-identical to before.

Repro (before this PR)

In any context that has no Win32 console buffer (e.g. an NSSM-wrapped Windows service spawning a child, a Task Scheduler task with no UI session, or subprocess.Popen(..., creationflags=DETACHED_PROCESS|CREATE_NO_WINDOW)):

hermes -p ops chat -q "hi"

…immediately exits with:

File "...\hermes-agent\cli.py", line 1528, in _cprint
    _pt_print(_PT_ANSI(text))
File "...\prompt_toolkit\shortcuts\utils.py", line 111, in print_formatted_text
    output = get_app_session().output
File "...\prompt_toolkit\application\current.py", line 67, in output
    self._output = create_output()
File "...\prompt_toolkit\output\defaults.py", line 91, in create_output
    return Win32Output(stdout, default_color_depth=color_depth_from_env)
File "...\prompt_toolkit\output\win32.py", line 219, in get_win32_screen_buffer_info
    raise NoConsoleScreenBufferError
prompt_toolkit.output.win32.NoConsoleScreenBufferError: No Windows console found. Are you running cmd.exe?

The crash happens at the first _cprint() call inside HermesCLI.chat (_cprint(f"{_DIM}Initializing agent...{_RST}")), so:

• Initializing agent... is never even printed.
• AIAgent.__init__ never runs.
• No agent log lines past plugin discovery + .env load.

Real-world impact

This is what motivated the fix. The kanban dispatcher (gateway/run.py -> plugins/kanban/...) launches each worker as hermes -p <profile> chat -q "work kanban task <id>". When the gateway runs under NSSM as a Windows service:

1. Dispatcher claims the task, spawns the child.
2. Child crashes inside ~1s on _cprint. PID is gone before any agent activity.
3. Dispatcher logs crashed=1 (only sees pid X not alive, no traceback in dispatcher log because the traceback went to the child's vanished stdout).
4. After max_retries, the task is auto-blocked.
5. Every kanban task on the board ends up blocked regardless of profile.

End-to-end verification of the fix:

• A task that had been auto-blocked with Agent crashed 2x: pid not alive was unblocked.
• On the next dispatcher tick the same hermes -p ops chat -q "..." invocation succeeded.
• ops worker ran 12 LLM calls and 8 tool calls (including a real docker build + docker run) and called kanban_complete. Task transitioned to done.

What this PR does

cli.py only:

1. Add a _safe_pt_print(text) helper near the top of the file. It calls _pt_print(_PT_ANSI(text)) inside try/except:
   • On NoConsoleScreenBufferError -> sys.stdout.write(text + "\n"); sys.stdout.flush().
   • On any other Exception from prompt_toolkit / IO -> same fallback. A failed colored print must never kill the agent.
2. Wrap the NoConsoleScreenBufferError import in try/except with a stub fallback class, so non-Windows installs (where prompt_toolkit.output.win32 may not be importable) still load cli.py cleanly.
3. Replace the 7 raw _pt_print(_PT_ANSI(text)) call sites inside _cprint() with _safe_pt_print(text). These are the sites that fire on every line printed via _cprint — banner, spinner frames, tool activity prefixes, streamed reasoning, etc.

The single remaining _pt_print(_PT_ANSI(str(line))) call site outside _cprint (the body of _emit_lines_to_pt, which is only reached after a prompt_toolkit Application is already running) is not changed in this PR — the issue does not surface there in practice and I'd rather keep the diff focused on the actually-broken path. Happy to extend if reviewers prefer.

Diff stats: cli.py | 58 ++++++++++++++++++++++++++++++++++++++++------- (51 insertions, 7 modifications, 0 deletions of pre-existing logic).

Why a wrapper instead of patching prompt_toolkit / forcing a fake console

• Wrapping _pt_print is the smallest possible change that fixes the crash without touching prompt_toolkit internals or assuming anything about the runtime.
• Fake-console approaches (winpty, pywinpty, AllocConsole) would have to be applied in every caller that ever spawns hermes as a child — gateway, dispatcher, NSSM wrappers, user scripts. The wrapper localizes the fix to cli.py.
• The wrapper is a no-op on the happy path: the inner call is the original _pt_print(_PT_ANSI(text)). Attached terminals (interactive cmd.exe, Windows Terminal, mintty/MSYS, conhost) hit the inner call and exit the try immediately — no measurable overhead.

Risks

• If the interactive path ever raised a non-NoConsoleScreenBufferError exception that the surrounding _cprint code relied on (e.g. via the except Exception branches at L1556, L1612), the new wrapper will swallow it and fall back to sys.stdout.write instead of letting the existing fallback _pt_print(_PT_ANSI(text)) run. In practice every existing _cprint fallback path already ends in _pt_print(_PT_ANSI(text)) — the wrapper just makes those last-resort prints themselves crash-safe. I think this is strictly better but it's the one behavior change worth a second pair of eyes.
• The wrapper imports sys under an alias (_sys_for_pt_fallback) to make absolutely sure no later import sys as ... shadow can break the fallback. Aesthetically ugly; happy to drop the alias if reviewers prefer.

Testing

Manual:

• Repro: subprocess.Popen([hermes_exe, "-p", "ops", "chat", "-q", "..."], creationflags=DETACHED_PROCESS|CREATE_NO_WINDOW, stdin=DEVNULL, stdout=PIPE, stderr=PIPE) — succeeds, Initializing agent... and the full agent response appear in stdout, exit code 0. Without the patch the same call exits non-zero with the traceback above.
• Real workload: kanban dispatcher under NSSM service runs a docker build task end-to-end via the ops profile.
• Interactive: hermes in Windows Terminal, mintty (Git Bash), and cmd.exe — banner/colors render identically to main.

I haven't added a unit test because exercising NoConsoleScreenBufferError reliably needs a non-trivial subprocess harness (the import itself works fine inside pytest — only create_output() blows up, and only when sys.stdout lacks a real console handle). Happy to add one in tests/ if reviewers point me at the right shape.

Environment

• Windows 11
• Python 3.12
• prompt_toolkit whatever ships with current requirements
• hermes-agent rebased on dd5a9502e (current main at PR open)