fix(copilot): bound auth JSON response reads

[ooiuuii]

Summary

Fixes #54749.

This bounds Copilot auth JSON response reads in hermes_cli.copilot_auth:

• device-code creation responses now use a limited JSON reader
• device-code polling responses now use the same limited reader
• Copilot token exchange responses now use the same limited reader
• oversized JSON responses fail with a clear diagnostic instead of buffering the whole body

The cap is 1 MiB, which is far above the expected size of these OAuth/token JSON payloads while still protecting the process from malformed upstream or proxy responses.

Testing

• C:\Users\Administrator\Documents\Codex\2026-06-29\hermes-openclaw-pattern-scan\.venv\Scripts\python.exe -m pytest tests\hermes_cli\test_copilot_auth.py tests\hermes_cli\test_copilot_token_exchange.py -q --basetemp .pytest-tmp-copilot-auth (39 passed)
• git diff --check

[tonydwb]

Code Review Summary

Verdict: LGTM

Security hardening: bounds Copilot OAuth response reads to 16 KB. Applied to device code initiation, polling, and token exchange endpoints.

Looks Good

• Consistent pattern with other response-bounding PRs
• Tests cover both device code and token exchange rejection paths
• Falls back properly when test doubles don't expose read(limit)

---

Reviewed by Hermes Agent

[tonydwb]

Code Review Summary

Verdict: LGTM

Clean fix to bound Copilot auth response reads. The implementation is well-structured with a reusable helper function and comprehensive tests for multiple paths.

Looks Good

• Clean helper function with descriptive label parameter
• Good test coverage for device code and token exchange paths
• Appropriate 1 MB limit for auth responses
• Follows established pattern from other response-bound fixes

---

Reviewed by Hermes Agent

[teknium1]

Thanks for the focused hardening work. The premise is still present on current main: hermes_cli/copilot_auth.py:202, :248, and :347 each call unbounded resp.read().

Problems

• In the PR, the polling call at hermes_cli/copilot_auth.py:253 uses the capped helper, but its ValueError is swallowed by the broad except Exception at :254-256. An oversized polling response is reduced to . retries and eventually a timeout, rather than the clear oversize diagnostic provided by the helper.

Suggested changes

• Catch the helper's ValueError separately in the polling loop, print the diagnostic, and return None; preserve retries for transient transport failures.
• Cover that branch with a valid initial device-code response followed by an oversized polling response.

Automated hermes-sweeper review.

[teknium1]

The surrounding except Exception catches this helper's oversize ValueError and turns it into another progress dot. Please handle that error separately so an oversized polling response fails with the clear diagnostic promised by this PR, while retaining retries for transport failures.