Skip to content

fix(cli): support Windows paste in setup secret prompts - #25540

Open
VinceZcrikl wants to merge 1 commit into
NousResearch:mainfrom
VinceZcrikl:fix/windows-setup-secret-paste
Open

VinceZcrikl wants to merge 1 commit into
NousResearch:mainfrom
VinceZcrikl:fix/windows-setup-secret-paste

Conversation

@VinceZcrikl

Copy link
Copy Markdown

Summary

Fix Windows setup/gateway secret prompts so pasted Telegram bot tokens and other hidden inputs can be entered reliably.

Problem

hermes setup and hermes gateway setup collect secret values through getpass.getpass(). On Windows, that path does not reuse the main CLI's prompt_toolkit paste handling, so Ctrl+V appears to do nothing in hidden prompts such as the Telegram bot token field.

Root cause

  • Messaging platform setup marks Telegram bot tokens as password=True.
  • The shared setup prompt path ultimately used plain getpass.getpass() for hidden input.
  • Hermes already has prompt_toolkit-based paste handling in the main CLI, but setup/gateway secret prompts were not using that input layer.

What changed

  • Centralized setup input sanitization in hermes_cli.cli_output.
  • Added
    ead_line() and
    ead_secret_line() helpers.
  • On interactive Windows TTYs,
    ead_secret_line() now uses a hidden prompt_toolkit prompt with Ctrl+V and bracketed paste handling.
  • Preserved getpass fallback outside that Windows/TTY path.
  • Updated hermes_cli.setup to reuse the shared helpers instead of maintaining a duplicate secret-input implementation.
  • Added focused tests covering the Windows prompt_toolkit path and the non-TTY fallback path.

Scope

This PR intentionally fixes the setup/gateway secret-prompt path only. It does not refactor every other getpass call site in the CLI.

Verification

  • pytest -v tests/hermes_cli/test_setup_prompt_menus.py tests/hermes_cli/test_cli_output.py
  • 7 tests passed locally.

Why this is not a duplicate

This is not the same as the existing work that strips bracketed-paste markers after input is already read, or the Windows getpass control-character sanitization work. This change addresses the missing paste-capable hidden-input path for Windows setup prompts themselves.

@VinceZcrikl

Copy link
Copy Markdown
Author
image

@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists comp/cli CLI entry point, hermes_cli/, setup wizard labels May 14, 2026
@alt-glitch

Copy link
Copy Markdown

Related to #25133 (strip ASCII control chars from getpass on Windows). Both address Windows getpass/paste issues in CLI but via different approaches — #25133 sanitizes output, this PR adds prompt_toolkit-based input with native paste support for setup secret prompts specifically.

@VinceZcrikl

Copy link
Copy Markdown
Author

Edition Windows 11 Pro
Version 25H2
Installed on ‎5/‎6/‎2026
OS build 26200.8457
Experience Windows Feature Experience Pack 1000.26100.304.0

@VinceZcrikl
VinceZcrikl force-pushed the fix/windows-setup-secret-paste branch from 96d74ee to d4c583d Compare June 5, 2026 23:28
@VinceZcrikl

Copy link
Copy Markdown
Author

Resolved the merge conflicts on this PR.

What changed:

  • Rebased fix/windows-setup-secret-paste onto the latest upstream/main and force-pushed the resolved branch with lease.
  • Preserved the current upstream masked_secret_prompt architecture and moved the Windows paste-friendly hidden-input handling into hermes_cli/secret_prompt.py.
  • Kept shared prompt helpers in hermes_cli/cli_output.py for visible/secret input sanitization, and updated setup to reuse those helpers.
  • Updated tests for Windows TTY prompt_toolkit input, getpass fallback sanitization, setup prompt delegation, and bracketed-paste marker cleanup.

Validation:

  • pytest -q tests/hermes_cli/test_cli_output.py tests/hermes_cli/test_secret_prompt.py tests/hermes_cli/test_setup_prompt_menus.py tests/hermes_cli/test_prompt_api_key.py → 26 passed
  • ruff check on the touched Python files passed
  • git diff --check upstream/main..HEAD passed

GitHub now reports mergeable=MERGEABLE; the remaining BLOCKED state appears to be non-conflict branch protection/review state.

@teknium1

Copy link
Copy Markdown
Collaborator

Thanks for preserving the existing masked-secret architecture and adding the Windows prompt_toolkit path. The underlying issue remains present on current main: hermes_cli/secret_prompt.py:68-105 still sends interactive Windows secret input through msvcrt.getwch().

Problems

  • hermes_cli/setup_whatsapp_cloud.py:178-181 still calls getpass.getpass() directly for secret=True. That path is used for the Access Token (:303-307) and App Secret (:344-348) in the WhatsApp Cloud setup wizard, exposed by hermes_cli/main.py:2689-2705 as hermes whatsapp-cloud. This file is not in the PR, so the same Windows hidden-prompt paste failure remains for those setup credentials.

Suggested changes

  • Route the WhatsApp Cloud secret path through masked_secret_prompt() or the shared secret helper, and add a delegation test for its token/secret prompts.

Automated hermes-sweeper review.

@alt-glitch alt-glitch added platform/windows Native Windows-specific behavior or breakage sweeper:risk-platform-windows Sweeper risk: may break or behave differently on native Windows labels Jul 13, 2026
@teknium1 teknium1 added sweeper:risk-security-boundary Sweeper risk: may affect sandboxing, auth, credentials, or sensitive data sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform labels Jul 13, 2026
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 P2 Medium — degraded but workaround exists platform/windows Native Windows-specific behavior or breakage sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:risk-platform-windows Sweeper risk: may break or behave differently on native Windows sweeper:risk-security-boundary Sweeper risk: may affect sandboxing, auth, credentials, or sensitive data type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants