fix: relaunch chat with a fresh tty after setup

[XiaoDcs]

Summary

• relaunch hermes chat after setup using a fresh /dev/tty-backed subprocess instead of os.execvp
• avoid inheriting broken stdin state from installer/setup flows such as curl ... | bash
• treat Invalid argument like other broken-stdin prompt_toolkit startup failures
• update setup tests to cover the new launch path

Problem

When Hermes is installed via the curl installer on macOS, the setup wizard can successfully run interactively by reading from /dev/tty, but choosing Launch hermes chat now? may immediately crash with:

• KeyError: '0 is not registered'
• OSError: [Errno 22] Invalid argument

This happens because the setup process re-execs into hermes chat, and the new prompt_toolkit app inherits a broken stdin/fd 0 state from the installer/setup chain.

Fix

Instead of replacing the current process with os.execvp, launch chat in a new subprocess wired directly to a freshly opened /dev/tty. This gives prompt_toolkit a clean TTY-backed stdin/stdout/stderr and avoids the broken inherited fd state.

As a small follow-up hardening step, the CLI stdin fallback now also treats Invalid argument as a broken-stdin startup error and prints the same friendly guidance instead of a raw traceback.

Testing

• venv/bin/python -m pytest tests/hermes_cli/test_setup.py -q
• manually verified printf "/exit\n" | hermes chat exits cleanly after the setup-launch change

[alt-glitch]

Likely duplicate of #6415 — same fix approach: replace os.execvp with a subprocess wired to a fresh /dev/tty. Also related to #10558 (non-TTY guard) and #13454 (reattach TTY before launch).

[teknium1]

Closing — superseded by #26077 (merged as commit d3d5916), which preventively probes kqueue at startup and falls back to SelectSelector when fd 0 cannot be registered. The widened except-clause matching EINVAL / EBADF / 'Invalid argument' — which most PRs in this cluster including yours added — is also included.

Thanks for the fix; closing as duplicate of the merged work.