You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Probe: can a setup-token credential read plan usage through claude -p /usage? #6963
User reports say a setup-token credential may lack the scope that plan-usage reads need. Run claude -p "/usage" --output-format stream-json --verbose under a setup-token credential on an idle machine and check whether the usage report's rate limits are present. Usage reads made within the last minute are shared across non-interactive sessions, so isolate the run.
Done when
A CI run's CLAUDE_CODE_OAUTH_TOKEN is a setup-token credential on an isolated runner, so a lane run can make this probe.
A comment on this issue records the Claude Code version, the credential type, and whether the /usage report from claude -p "/usage" --output-format stream-json --verbose carries its rate limits (key names and presence only, no token or account identifiers).
Understood: this is a bounded probe. Run claude -p "/usage" --output-format stream-json --verbose under a setup-token credential on an isolated, idle runner. Then record the Claude Code version, the credential type, and whether the usage report carries its rate-limit keys. Record key names and presence only, with no tokens or account identifiers. The run needs a real claude invocation, which the issue lane can't make. Admission handles that split. No duplicates found among the open issues.
Released by the owner's HITL session (2026-10-24, C12): it waited only on a removed gate. Intake triage re-runs on it to set its fields, then admission takes it.
Needs a run of claude (eval, probe or /usage), which the issue lane cannot do (pr-pipeline.yaml:289-314). The owner's HITL session runs it on the operator machine; no owner action needed.
The work-resolve-issue lane stopped partway through this issue and needs a person.
Why, in the run's own words:
Issue #6963 can only be finished by running claude -p "/usage" --output-format stream-json --verbose under a setup-token CLAUDE_CODE_OAUTH_TOKEN on an isolated runner and then commenting the result on the issue. This lane cannot do either step. Its Bash runs only the named check, verify and git-read wrappers, so it cannot start claude. It holds no write token and cannot comment on issues (docs/conventions/pr-pipeline.yaml:270-319). Nothing in the issue is a repository change. The owner's 2026-10-25 comment says the same: the owner's HITL session runs the probe on the operator machine. The item belongs with that session, not this lane.
What the run says it did not do:
Running claude -p "/usage" --output-format stream-json --verbose under a setup-token credential: this lane's Bash runs only the named wrappers and cannot start claude
Posting the result comment on issue #6963: the lane holds no write token, and the comment is the issue's only Done-when item
Fresh-context review, build, test and lint: skipped because there is no diff to review or verify
Routed to the host runner, not the owner. The probe needs claude -p "/usage" under a setup-token credential (https://github.com/melodic-software/claude-code-plugins/actions/runs/40213565240). Nothing on main reads /usage today, so the host runner first checks whether anything still needs the answer, and closes this if nothing does.
Under the owner's 2026-10-26 stop rule, a person is needed only for a change in intent or vision, an implementation finding that changes the intent or primary design, or a high or critical security issue; host, attended and eval runs are agent work. So needs-human comes off. It moves to the host-run label, and the host runner takes it.
Host run. Checked whether this host holds a setup-token credential for the claude -p "/usage" probe; it does not, so the probe did not run.
What ran:
Claude Code version: claude --version reports 2.1.312.
Credential check: CLAUDE_CODE_OAUTH_TOKEN is unset in the host session, and the operator notes name no setup-token credential set aside for probes on this host. No credential store was read and no token was created.
Consumer check: git grep over origin/main finds nothing that reads claude -p "/usage" output. The only hits are an intake-triage test fixture that quotes this issue's text (.github/scripts/intake-triage/admit.test.mjs:1078) and the unrelated /usage-now mod experiments under docs/upstream/claude-code-mods/.
Against the Done-when item (version, credential type, and whether the /usage report carries its rate limits): not covered. The probe needs a setup-token credential this host does not have. A CI lane run under the repository's CLAUDE_CODE_OAUTH_TOKEN secret could make it, or the issue could close if nothing needs the answer, since nothing on main reads /usage today.
No PR opened.
Recommend closing as not planned: the close condition in #6963 (comment) holds. On origin/main, /usage appears only in docs and rules (.claude/rules/cost-claims.md, docs/upstream/); no code reads its output. If a reader appears, reopen this issue and run the probe in a CI lane under the repo's CLAUDE_CODE_OAUTH_TOKEN secret.
Closing as not planned under this issue's own close condition (#6963 (comment)): nothing on main reads claude -p "/usage" output (git grep finds only docs and rule mentions). Resume step: if a reader appears, reopen and run the probe in a CI lane under the repository's CLAUDE_CODE_OAUTH_TOKEN secret.
Activity
github-actions commentedon Oct 11, 2026
Proposed work class: work-class: read-only
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Low
Uncertainty: Knowable
Flags: none
Blocked by: none
Understood: this is a bounded probe. Run
claude -p "/usage" --output-format stream-json --verboseunder a setup-token credential on an isolated, idle runner. Then record the Claude Code version, the credential type, and whether the usage report carries its rate-limit keys. Record key names and presence only, with no tokens or account identifiers. The run needs a realclaudeinvocation, which the issue lane can't make. Admission handles that split. No duplicates found among the open issues.Automated triage, applied by the lanes App.
kyle-sexton commentedon Oct 24, 2026
Released by the owner's HITL session (2026-10-24, C12): it waited only on a removed gate. Intake triage re-runs on it to set its fields, then admission takes it.
kyle-sexton commentedon Oct 25, 2026
Needs a run of
claude(eval, probe or /usage), which the issue lane cannot do (pr-pipeline.yaml:289-314). The owner's HITL session runs it on the operator machine; no owner action needed.github-actions commentedon Oct 25, 2026
The triage sweep dispatched intake triage for this issue (attempt 1 of 2).
melodic-automation-lanes commentedon Oct 25, 2026
The work-resolve-issue lane stopped partway through this issue and needs a person.
Why, in the run's own words:
What the run says it did not do:
claude -p "/usage" --output-format stream-json --verboseunder a setup-token credential: this lane's Bash runs only the named wrappers and cannot startclaudeRun: https://github.com/melodic-software/claude-code-plugins/actions/runs/40213565240
To retry, remove
needs-humanand addagent-readyagain.kyle-sexton commentedon Oct 26, 2026
This was generated by AI.
Routed to the host runner, not the owner. The probe needs
claude -p "/usage"under a setup-token credential (https://github.com/melodic-software/claude-code-plugins/actions/runs/40213565240). Nothing on main reads/usagetoday, so the host runner first checks whether anything still needs the answer, and closes this if nothing does.Under the owner's 2026-10-26 stop rule, a person is needed only for a change in intent or vision, an implementation finding that changes the intent or primary design, or a high or critical security issue; host, attended and eval runs are agent work. So
needs-humancomes off. It moves to thehost-runlabel, and the host runner takes it.kyle-sexton commentedon Oct 28, 2026
Host run. Checked whether this host holds a setup-token credential for the
claude -p "/usage"probe; it does not, so the probe did not run.What ran:
claude --versionreports 2.1.312.CLAUDE_CODE_OAUTH_TOKENis unset in the host session, and the operator notes name no setup-token credential set aside for probes on this host. No credential store was read and no token was created.git grepover origin/main finds nothing that readsclaude -p "/usage"output. The only hits are an intake-triage test fixture that quotes this issue's text (.github/scripts/intake-triage/admit.test.mjs:1078) and the unrelated/usage-nowmod experiments underdocs/upstream/claude-code-mods/.Against the Done-when item (version, credential type, and whether the
/usagereport carries its rate limits): not covered. The probe needs a setup-token credential this host does not have. A CI lane run under the repository'sCLAUDE_CODE_OAUTH_TOKENsecret could make it, or the issue could close if nothing needs the answer, since nothing on main reads/usagetoday.No PR opened.
Recommend closing as not planned: the close condition in #6963 (comment) holds. On origin/main,
/usageappears only in docs and rules (.claude/rules/cost-claims.md,docs/upstream/); no code reads its output. If a reader appears, reopen this issue and run the probe in a CI lane under the repo'sCLAUDE_CODE_OAUTH_TOKENsecret.kyle-sexton commentedon Oct 28, 2026
Closing as not planned under this issue's own close condition (#6963 (comment)): nothing on main reads
claude -p "/usage"output (git grepfinds only docs and rule mentions). Resume step: if a reader appears, reopen and run the probe in a CI lane under the repository'sCLAUDE_CODE_OAUTH_TOKENsecret.