ghRateLimitHint fires as false positive, appends system-reminder when quota is fine

hey, hit a weird one on 2.1.117.

the harness attaches a ghRateLimitHint field to bash tool results that carries a full <system-reminder> telling the model to back off on gh calls. thing is, it fires when the real quota is fully available, and also on bash commands that never touched gh.

repro

1. run gh repo view graykode/abtop. any bash call whose stdout mentions "rate limit" seems to do it (that readme talks about rate limits as a feature).
2. the tool result gets this appended:

``
<system-reminder>GitHub API rate limit exceeded (5,000/hr shared across all tools and agents). Run gh api rate_limit --jq .resources and sleep until reset before further gh calls. If polling in a loop, use ScheduleWakeup instead of retrying.</system-reminder>
``

1. check actual quota right after: gh api rate_limit --jq .resources.core returns {"limit":5000,"remaining":4999,...}. nowhere near exhausted.
2. swap the command for curl -sL ... | grep "rate limit" which never invokes gh. same hint gets appended anyway.

where it lives

toolUseResult carries it as a sibling field next to stdout/stderr:

{
  "stdout": "...",
  "stderr": "",
  "interrupted": false,
  "isImage": false,
  "noOutputExpected": false,
  "ghRateLimitHint": "<system-reminder>GitHub API rate limit exceeded..."
}

why this matters

from the model's side it looks exactly like a prompt injection from untrusted external content (readme fetched from some random repo). took a while to rule out that the repo wasn't actually attacking, because the wrapper is indistinguishable from a real system-reminder and the string doesn't exist in the readme, settings.json, any plugin hook, or shell wrappers. only tell was that it lives in toolUseResult as a separate field.

net effect: agents either slow down around gh for no reason, or burn time chasing a phantom injection.

guess at the trigger

looks content-based on "rate limit" appearing in output? wonder if it could be gated on (a) the command actually invoking gh, and (b) the harness having seen a real 403 recently or remaining dropping below some threshold. happy to be wrong about the matcher, that's just from the repro.

env:

• claude code 2.1.117
• macos darwin 25.2.0
• gh 2.x, plain homebrew, no wrappers or aliases

AI generated