Bug Description
Shift+Enter stopped inserting a newline in the classic Hermes CLI chat input. Instead, Enter behavior changed in a way that broke multiline composition in normal local terminal usage on macOS.
This appears to have regressed after the LF-submit fix for thin PTYs. In my case, Shift+Enter used to be a practical multiline shortcut and then stopped working.
Steps to Reproduce
- Start classic Hermes CLI with
hermes (not hermes --tui).
- Type part of a message.
- Press Shift+Enter.
- Observe that no newline is inserted / multiline composition is broken.
Expected Behavior
In the classic CLI, Shift+Enter should insert a newline so multiline prompts can be composed normally.
Actual Behavior
Shift+Enter no longer inserts a newline. The CLI treats LF / c-j as submit, which breaks terminals that deliver Shift+Enter as LF / c-j.
Affected Component
CLI (interactive chat)
Messaging Platform (if gateway-related)
N/A (CLI only)
Debug Report
Report https://paste.rs/1Lg8U
agent.log https://paste.rs/U0uXO
gateway.log https://paste.rs/iJqBj
Operating System
MacOS Sequoia
Python Version
3.14.4
Hermes Version
Hermes Agent v0.13.0 (2026.5.7)
Additional Logs / Traceback (optional)
None captured for this bug.
Root Cause Analysis (optional)
The relevant upstream change appears to be:
fix(cli): submit LF enter in thin PTYs (commit 5044e1cbf)
In cli.py, _bind_prompt_submit_keys() was changed to bind both enter and c-j to submit. On terminals where Shift+Enter is delivered as LF / c-j, this makes Shift+Enter submit instead of inserting a newline.
Proposed Fix (optional)
For normal local CLI use, bind only enter to submit by default.
Handle c-j separately so it inserts \n by default, and gate LF-submit behind an opt-in environment variable for thin PTYs, e.g. HERMES_CLI_SUBMIT_ON_LF=1.
A working local pattern was:
_bind_prompt_submit_keys() binds only enter
@kb.add('c-j') inserts newline by default
- when
HERMES_CLI_SUBMIT_ON_LF=1 is set, the c-j handler calls handle_enter(event) instead
Are you willing to submit a PR for this?
Bug Description
Shift+Enter stopped inserting a newline in the classic Hermes CLI chat input. Instead, Enter behavior changed in a way that broke multiline composition in normal local terminal usage on macOS.
This appears to have regressed after the LF-submit fix for thin PTYs. In my case, Shift+Enter used to be a practical multiline shortcut and then stopped working.
Steps to Reproduce
hermes(nothermes --tui).Expected Behavior
In the classic CLI, Shift+Enter should insert a newline so multiline prompts can be composed normally.
Actual Behavior
Shift+Enter no longer inserts a newline. The CLI treats LF /
c-jas submit, which breaks terminals that deliver Shift+Enter as LF /c-j.Affected Component
CLI (interactive chat)
Messaging Platform (if gateway-related)
N/A (CLI only)
Debug Report
Operating System
MacOS Sequoia
Python Version
3.14.4
Hermes Version
Hermes Agent v0.13.0 (2026.5.7)
Additional Logs / Traceback (optional)
None captured for this bug.Root Cause Analysis (optional)
The relevant upstream change appears to be:
fix(cli): submit LF enter in thin PTYs(commit5044e1cbf)In
cli.py,_bind_prompt_submit_keys()was changed to bind bothenterandc-jto submit. On terminals where Shift+Enter is delivered as LF /c-j, this makes Shift+Enter submit instead of inserting a newline.Proposed Fix (optional)
For normal local CLI use, bind only
enterto submit by default.Handle
c-jseparately so it inserts\nby default, and gate LF-submit behind an opt-in environment variable for thin PTYs, e.g.HERMES_CLI_SUBMIT_ON_LF=1.A working local pattern was:
_bind_prompt_submit_keys()binds onlyenter@kb.add('c-j')inserts newline by defaultHERMES_CLI_SUBMIT_ON_LF=1is set, thec-jhandler callshandle_enter(event)insteadAre you willing to submit a PR for this?