fix(pairing): stop labeling hash fingerprint as 'Code' in list output

[lhridley]

Problem

hermes pairing list displayed hash_val[:8] (the first 8 hex chars of the
pairing code's SHA-256 hash) under a column labeled "Code". Operators
reasonably copied that value and ran hermes pairing approve <platform> <code>,
which always failed with "Code '…' not found or expired" — the fingerprint is
never an approvable code. The real code is only delivered via the bot's DM.
This produced an endless approval loop (verified symptom: the same user
generated a fresh pending code on every DM, each showing a different
non-approvable fingerprint).

Fix

• list: relabel the column to "Request ID" and add a note pointing the
  operator to the DM-sent code.
• approve: reject an 8-hex fingerprint input explicitly with guidance instead
  of the cryptic "not found" error.

Verification

Local import + stubbed gateway.pairing: an 8-hex fingerprint input is
rejected without calling approve_code, and prints the corrective message.
Syntax + static checks pass. No token/secret touched.

Note

The fix only affects CLI ergonomics for authorizing new users; existing
approved users are unaffected.

[alt-glitch]

This was generated by AI during triage.

Related to #46584: this PR prevents the misleading hash-prefix workflow in the CLI, while #46584 makes a listed server-side request ID actually approvable across CLI and dashboard. The approaches overlap but are not redundant.

[tonydwb]

Code Review Summary

Verdict: Approved

Straightforward UX fix that correctly renames the "Code" column to "Request ID" in hermes pairing list output, since the displayed value is the SHA-256 hash prefix — not the actual approvable code (which comes from the bot's DM). Also adds a helpful note explaining this distinction and includes a regex guard to reject the 8-char hex hash input and guide the operator to the correct code source. The test in the diff validates the rejection of hash-prefix input.

---

Reviewed by Hermes Agent

[tonydwb]

Reviewed by Hermes Agent

[tonydwb]

Reviewed by Hermes Agent

[teknium1]

Thanks for addressing a real CLI mismatch: current main labels a hash prefix as a code even though the DM contains the actual approvable value (hermes_cli/pairing.py:42-47, gateway/pairing.py:542-565).

Problems

• hermes_cli/pairing.py:82 rejects any eight-character hexadecimal input. That can be a valid generated code: gateway/pairing.py:43-44 uses an eight-character alphabet containing A-F and 2-9, so a value such as ABCDEF23 is possible and should reach approve_code().
• The new Request ID heading is not exact. The displayed field is a truncated hash prefix; the actual stored entry ID is generated separately (gateway/pairing.py:453-458, gateway/pairing.py:561-565).

Suggested changes

• Detect a displayed fingerprint by comparing against pending entries for the platform, not by matching its character shape; add a regression test that an all-hex valid code remains approvable.
• Rename the column to Fingerprint/Hash prefix, or expose a real request ID if that is the intended contract.

Automated hermes-sweeper review.

[teknium1]

This guard also rejects legitimate pairing codes. gateway/pairing.py generates eight-character codes from an alphabet containing A-F and 2-9, so ABCDEF23 is valid and must reach approve_code(). Identify an input as a displayed fingerprint by comparing it with pending fingerprints, not by its shape.

[teknium1]

The displayed value is a truncated SHA-256 hash prefix, not the stored request entry ID (gateway/pairing.py:453-458, gateway/pairing.py:561-565). Fingerprint or Hash prefix would be accurate here.

[OutThisLife]

Your diagnosis was right: the value under "Code" is a hash fingerprint that can never be approved, and operators were looping on it. #74427 fixes it structurally rather than by relabeling — pending entries now carry a real request_id that hermes pairing approve accepts, so there's no longer a non-approvable value on screen to guard against. Thanks for the writeup; the reproduction made the root cause obvious.