hermes - 💡(How to fix) Fix Interactive CLI hides tool output despite display.tool_progress=all, and hermes chat -v does not restore it [1 pull requests]

Summary

Normal Hermes CLI sessions can hide tool result bodies even when display.tool_progress: all is configured. The active control path appears to couple agent quiet_mode to the CLI -v/--verbose flag, but in the affected install even hermes chat -v does not restore visible tool output for the user.

This looks like a recent main-session Hermes core regression, not a plugin issue.

Regression note

This behavior appears recent.

About two days ago, the same interactive Hermes workflow showed both tool progress and tool results normally. The output-hiding behavior started recently without intentionally switching to a different runtime model or provider setup.

Environment

Observed on:

• OS: Microsoft Windows 11 Pro
• OS version/build: 10.0.26200, build 26200.8457
• Shell: pwsh / PowerShell Core 7.6.0
• Hermes version: Hermes Agent v0.14.0 (2026.5.16)
• Python: 3.11.14
• Local checkout: 10ee4a729ba22c00718ca12d5192a52e56fb5a09
• Provider/model in the affected session:
  • provider: zai-anthropic
  • model: glm-5.1
• Approvals mode: manual

This is not a Codex runtime session and does not depend on OpenAI/Codex models being active.

zai-anthropic here is a custom provider wired through a provider plugin / local customization, not a stock upstream provider, but the bug reproduces in the normal Hermes interactive CLI path rather than in any custom transport layer.

How Hermes is launched

The affected workflow is a normal interactive Hermes session started from PowerShell.

In this install, hermes in pwsh is a PowerShell function that routes interactive chat-like invocations through:

• C:\Users\innad\AppData\Local\hermes\wrapper_cli.py

and non-interactive commands through:

• C:\Users\innad\AppData\Local\hermes\hermes-agent\venv\Scripts\hermes.exe

The function definition currently sends interactive/default/--resume/--continue usage through the wrapper.

So the bug is being observed in the real Windows pwsh interactive launch path, not in a custom one-off script.

Actual behavior

In a normal interactive Hermes CLI session:

• tool progress lines appear
• the user can see that terminal, execute_code, read_file, or write_file ran
• the actual tool output body is often not rendered in the TUI the way a user would expect
• this can make tool output look "hidden" even when the agent itself received the result

A second important observation: launching with hermes chat -v does not produce a meaningful change in what the user actually sees. The suspected quiet_mode / verbosity coupling exists in source, but -v is not fixing the visible symptom in practice in this environment.

Expected behavior

If display.tool_progress: all is enabled, normal interactive sessions should not silently fall into a compact rendering path that suppresses tool result bodies unless the user explicitly asked for that behavior.

Also, if -v/--verbose is intended to control quiet-vs-full tool rendering, it should produce a real visible change. Right now it does not.

At minimum, the control surface for:

• progress visibility
• full tool-result body visibility
• quiet compact rendering
• verbose mode

should be coherent and should match observed runtime behavior.

Current config / runtime context

From the affected local install:

• display.tool_progress: all
• tool_preview_length: 0
• provider/model are standard Hermes CLI config, not Codex runtime

Relevant config facts from local source snapshot:

• config.yaml:279 -> tool_preview_length: 0
• config.yaml:291 -> tool_progress: all

Also, tool_preview_length: 0 does not appear to mean "hide output"; source comments indicate it means unlimited preview length.

Suspected root cause

The likely active coupling is in normal CLI agent construction:

• hermes-agent/cli.py:2953
  • self.verbose = bool(verbose) if verbose is not None else False
• hermes-agent/cli.py:4964
  • quiet_mode=not self.verbose

And -v/--verbose is defined on the hermes chat parser:

• hermes-agent/hermes_cli/_parser.py:272
• hermes-agent/hermes_cli/_parser.py:273

This suggests that a normal non-verbose chat session gets quiet_mode=True, regardless of display.tool_progress configuration.

However, because hermes chat -v does not visibly fix the issue in the affected environment, there may be an additional rendering path or suppression layer involved beyond this coupling.

Important non-cause

This does not appear to be caused by:

• custom permission plugin policy
• wrapper bootstrap logic
• Codex runtime event projection
• tool_preview_length: 0

There is also a separate intentional large-result persistence path:

• hermes-agent/tools/tool_result_storage.py:122

That explains some oversized-result preview/truncation behavior, but it does not explain the broader symptom of normal tool output being hidden in ordinary interactive sessions.

Repro

1. Open a normal pwsh session on Windows.
2. Start Hermes normally through the standard hermes command.
3. Ensure display.tool_progress: all is set.
4. Run tools that produce visible output, for example:
   • terminal
   • execute_code
   • read_file
5. Observe that tool progress is visible, but tool result bodies may not be rendered as expected.
6. Repeat with hermes chat -v.
7. Observe that -v does not meaningfully restore user-visible tool output in the TUI.

Why this is confusing

The current behavior appears to expose multiple conflicting control layers:

• display config suggests tool output should be shown
• source suggests quiet mode depends on CLI verbosity
• actual runtime behavior suggests -v still does not restore visible output

That makes the observable behavior look like a regression or a broken control-surface contract.

Suggested fix direction

1. Confirm whether quiet_mode=not self.verbose is still the real winner in current interactive sessions.
2. Trace the actual TUI rendering path for tool result bodies in normal CLI sessions.
3. Decouple full tool-result rendering from -v/--verbose, or make the interaction between:
   • display.tool_progress
   • quiet mode
   • verbose mode explicit and user-configurable.
4. If compact quiet rendering is intentional, it should be controlled by a dedicated display setting rather than implicitly by CLI verbosity.
5. If -v is intended to restore full output, fix the path so it actually does.