Skip to content

feat(cli): mint agent tokens in the binary instead of workflows - #2389

Merged
waynesun09 merged 1 commit into
mainfrom
worktree-mint-in-binary
Jun 24, 2026
Merged

feat(cli): mint agent tokens in the binary instead of workflows#2389
waynesun09 merged 1 commit into
mainfrom
worktree-mint-in-binary

Conversation

@ggallen

@ggallen ggallen commented Jun 17, 2026

Copy link
Copy Markdown
Member

Summary

  • Adds mintAgentToken() to fullsend run that calls the mint service using the harness's role field, setting GH_TOKEN and role-specific env vars (PUSH_TOKEN, REVIEW_TOKEN) before env expansion
  • Removes token passthrough env vars from all 6 reusable workflow files — workflows retain mint-token action only for actions/checkout
  • Adds MINT_REPOS env var support for retro's multi-repo case
  • Makes agents self-contained: the harness role field now drives token acquisition at runtime, implementing the binary-side token minting described in ADR-0029 (Central token mint) and leveraging the role field introduced by ADR-0045 (Portable harness schema)

Test plan

  • All 25+ unit tests pass (TestMintAgentToken_*, TestResolveMintRepos_*, TestRoleTokenVars_*, TestSetupStatusNotifier_Factory*)
  • Coverage on mintAgentToken and resolveMintRepos functions
  • Full make go-test passes (including -race)
  • make go-vet and make lint pass
  • Deploy to test org, trigger each agent type (code, triage, review, fix, retro, prioritize), verify tokens work end-to-end

🤖 Generated with Claude Code

@github-actions

github-actions Bot commented Jun 17, 2026

Copy link
Copy Markdown

Site preview

Preview: https://367a82b3-site.fullsend-ai.workers.dev

Commit: 277e2b4dbdf593fcde1737592296baf49f08ed34

@fullsend-ai-review

fullsend-ai-review Bot commented Jun 17, 2026

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 2:26 PM UTC · Completed 2:44 PM UTC
Commit: b14cf6f · View workflow run →

@codecov

codecov Bot commented Jun 17, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 97.80220% with 2 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
internal/cli/run.go 97.72% 1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

@fullsend-ai-review

fullsend-ai-review Bot commented Jun 17, 2026

Copy link
Copy Markdown

Review

Findings

High

  • [protected-path] .github/workflows/reusable-{code,fix,prioritize,retro,review,triage}.yml — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Human approval is required regardless of context.
    Remediation: Link an issue that documents authorization for this change, or obtain explicit human approval on the PR.

  • [breaking-config] .github/workflows/reusable-*.yml — Removed CODE_GH_TOKEN, FIX_GH_TOKEN, PRIORITIZE_GH_TOKEN, RETRO_GH_TOKEN, TRIAGE_GH_TOKEN, PUSH_TOKEN, PUSH_TOKEN_SOURCE, and REVIEW_TOKEN env var passthrough from 6 reusable workflow files. Consuming repos with custom pre/post scripts or env files that reference these workflow-level variables will see them unset. The binary now mints tokens internally via mintAgentToken() and sets them via os.Setenv before env expansion, so standard harness configs are unaffected — but no migration documentation exists for non-standard installations.
    Remediation: Add migration documentation explaining that these env vars are no longer set at workflow scope. Consumers with custom scripts should rely on the binary's integrated mint functionality via --mint-url.

Low

  • [breaking-config] action.yml — Changed mint-url input semantics from "status comment tokens only" to "status + agent runtime tokens." The --mint-url flag is now passed to fullsend run outside the status-only conditional block, enabling binary-side token minting. Consumers passing mint-url for status comments will now also trigger runtime token minting. In practice, the minted token permissions are identical (same role-scoped mint service), so no consumer action is required.

  • [scope-creep] docs/plans/adr-0045-forge-portable-harness-phase2.md — The diff adds supersession annotations and inline changes referencing PR feat(cli): mint agent tokens in the binary instead of workflows #2389 before this PR merges. While plan docs are living documents and this is cosmetic, annotations referencing an unmerged PR create a temporarily circular reference.

  • [missing-authorization] — This PR implements a significant architectural change (moving token minting from workflows into the binary) without a linked issue. The PR body documents the rationale and references ADR-0029 and ADR-0045, providing inline context, but no traceable authorization artifact (issue, RFC) exists.

Note: Prior medium findings from earlier iterations are resolved — the dead-code warning branch (!minted && mintURL != "" && h.Role == "") has been replaced with a reachable condition (!minted && mintURL == ""), token validation in setupStatusNotifier and reconcilestatus.go now correctly rejects malformed tokens before use, and the statusMintToken godoc comment placement is fixed.

Previous run

Review

Findings

High

  • [protected-path] .github/workflows/reusable-{code,fix,prioritize,retro,review,triage}.yml — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Human approval is required regardless of context.
    Remediation: Link an issue that documents authorization for this change, or obtain explicit human approval on the PR.

  • [breaking-config] .github/workflows/reusable-*.yml — Removed CODE_GH_TOKEN, FIX_GH_TOKEN, PRIORITIZE_GH_TOKEN, RETRO_GH_TOKEN, TRIAGE_GH_TOKEN, PUSH_TOKEN, PUSH_TOKEN_SOURCE, and REVIEW_TOKEN env var passthrough from 6 reusable workflow files. Consuming repos that reference these variables in custom pre/post scripts or env files will see them unset. The binary now mints tokens internally via mintAgentToken(), but no migration documentation exists.
    Remediation: Add migration documentation explaining that these env vars are no longer set by workflows. Consumers should rely on the binary to mint tokens via --mint-url, or set GH_TOKEN/PUSH_TOKEN/REVIEW_TOKEN directly.

Medium

  • [logic-error] internal/cli/run.go:347 — The warning branch !minted && mintURL != "" && h.Role == "" in runAgent is dead code. Harness validation (Load/LoadWithOpts) already requires h.Role to be non-empty — the warning "Harness has no role field; cannot mint tokens..." can never be emitted.

  • [scope-creep] docs/plans/adr-0045-forge-portable-harness-phase2.md:255 — The diff adds (superseded by PR #2389) annotations to the ADR-0045 phase 2 plan before this PR merges, creating a circular reference. Plan updates referencing their own PR should be applied after merge.

  • [architectural-conflict] internal/cli/run.go:362mintAgentToken() uses os.Setenv to inject tokens into global process state before env expansion. While the code correctly warns about goroutine safety and this is the natural integration point with RunnerEnv expansion, it creates a global side effect rather than explicit credential delivery. Consider returning a map[string]string of minted vars for explicit passing if concurrent minting is ever needed.

  • [breaking-config] action.yml:149 — Changed mint-url input semantics from "status comment tokens only" to "status + agent runtime tokens." Consumers passing mint-url for status comments only will now automatically trigger runtime token minting, broadening scope.

  • [comment-placement] internal/cli/run.go:49 — The comment block starting at line 49 describes agentWorkingDirExcludes but is attached to var statusMintToken. The new lines about statusMintToken extend the misplaced comment, creating a godoc block that opens with unrelated content.

Low

  • [fail-open] internal/cli/run.go:355 — When mintURL is empty and role is non-empty, mintAgentToken returns (false, noop, nil) and the caller emits only a warning. The agent proceeds without tokens. By design for local development, but a soft fail-open in CI if --mint-url is accidentally omitted from the workflow dispatch.

  • [missing-documentation] docs/guides/user/building-custom-agents.md:149 — Example harness shows GH_TOKEN: "${GH_TOKEN}" in runner_env without documenting that it's auto-minted in CI when --mint-url is provided. Other guides (customizing-agents.md, running-agents-locally.md) were updated with auto-minting comments but this guide was not.

  • [missing-authorization] — This PR implements a significant architectural change without a linked issue. The PR body documents the rationale and references ADR-0029 and ADR-0045, providing inline context, but no traceable authorization artifact (issue, RFC) exists.

Note: Prior medium findings from earlier iterations remain resolved — the empty-role-with-mintURL silent pass-through has explicit warning branches, TestMintAgentToken_CoderRole uses defer cleanup(), and token validation in setupStatusNotifier and reconcilestatus.go now rejects malformed tokens before masking.

Previous run (2)

Review

Findings

High

  • [protected-path] .github/workflows/reusable-{code,fix,prioritize,retro,review,triage}.yml — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Human approval is required regardless of context.
    Remediation: Link an issue that documents authorization for this change, or obtain explicit human approval on the PR.

Low

  • [fail-open] internal/cli/run.go:355 — When mintURL is empty and role is non-empty, mintAgentToken returns (false, noop, nil) and the caller emits only a warning. The agent proceeds without tokens. By design for local development, but a soft fail-open in CI if --mint-url is accidentally omitted from the workflow dispatch.

  • [missing-documentation] docs/ADRs/0024-harness-definitions.md:476 — Harness definitions ADR shows GH_TOKEN: ${GH_TOKEN} in api_servers and required_env examples without noting that GH_TOKEN is now auto-minted by the binary when --mint-url is provided. The ADR is frozen (Accepted status), so the user-facing guides (updated in this PR) are the appropriate place for this context — but a brief annotation in the ADR would aid discoverability.

Note: Two prior medium findings are resolved in this iteration — the empty-role-with-mintURL silent pass-through now has an explicit warning branch (line 364), and TestMintAgentToken_CoderRole now uses defer cleanup() (line 636). The token validation pattern in setupStatusNotifier and reconcilestatus.go is also improved: tokens failing mintTokenPattern are now rejected with an error before masking, matching the stricter pattern already used in minttoken.go.

Previous run (3)

Review

Findings

High

  • [protected-path] .github/workflows/reusable-{code,fix,prioritize,retro,review,triage}.yml — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Human approval is required regardless of context.
    Remediation: Link an issue that documents authorization for this change, or obtain explicit human approval on the PR.

Medium

  • [logic-error] internal/cli/run.go:357 — When mintURL is non-empty but the harness role is empty (misconfigured harness YAML missing the role: field), mintAgentToken silently returns (false, func(){}, nil). The caller only warns when !minted && mintURL == "", so this case emits no warning. The agent proceeds without GH_TOKEN/PUSH_TOKEN/REVIEW_TOKEN, leading to opaque failures downstream.
    Remediation: Adjust the post-mint warning condition to also cover the case where mintURL is non-empty but role is empty, e.g. if !minted { printer.StepWarn(...) }.

  • [test-integrity] internal/cli/run_test.go:609TestMintAgentToken_CoderRole calls cleanup() inline rather than via defer. If an assertion between the mintAgentToken call and cleanup() fails, the process environment remains mutated with minted token values. While t.Setenv partially mitigates this by restoring the original values on test exit, the minted values persist until that deferred restore runs.
    Remediation: Use defer cleanup() immediately after the mintAgentToken call in affected tests.

  • [token-minting-precedence] internal/cli/run.go:328 — The binary now mints agent tokens (GH_TOKEN, PUSH_TOKEN, REVIEW_TOKEN) before env var expansion in runner_env. Minted tokens silently override any pre-existing values of these env vars. External consumers who previously set these env vars manually will see them replaced when --mint-url is provided.
    Remediation: Document this behavior change in release notes.

Low

  • [architectural-drift] internal/cli/run.go:350 — This PR shifts token minting from workflow-side to binary-side, which changes the integration point described in ADR-0029 Decision point 4. While the workflow still "obtains" the token (the binary runs within it), the responsibility boundary has shifted.

  • [scope-documentation-mismatch] internal/cli/run.go:350 — PR body claims this change "implements binary-side token minting described in ADR-0029", but ADR-0029 describes workflow-level integration, not binary-side minting specifically.

  • [error-message-consistency] internal/cli/run.go:453 — Error message format "minting agent token for role %s" includes role context, whereas similar errors in reconcilestatus.go ("minting status token") and minttoken.go ("minting token") omit it. Minor inconsistency.

  • [fail-open] internal/cli/run.go:355 — When mintURL is empty and role is non-empty, mintAgentToken returns (false, noop, nil) and the caller emits only a warning. The agent proceeds without tokens. By design for local development, but a soft fail-open in CI if --mint-url is accidentally omitted.

  • [stale-reference] docs/guides/user/running-agents-locally.md:227 — Added comment says tokens are "auto-minted by the binary" but the code example still shows PUSH_TOKEN_SOURCE=github-app without explaining that this metadata string is auto-set during minting and may not apply to manually-supplied PATs.

Previous run (4)

Review

Findings

High

  • [protected-path] .github/workflows/reusable-{code,fix,prioritize,retro,review,triage}.yml — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Human approval is required regardless of context.
    Remediation: Link an issue that documents authorization for this change, or obtain explicit human approval on the PR.

Low

  • [error-message-format] internal/cli/run.go — Inconsistent error phrasing between mintAgentToken ("mint returned token with unexpected characters for role %s") and reconcilestatus.go / setupStatusNotifier ("minted status token contains unexpected characters"). Using consistent verb forms across the three token validation sites would improve readability.

  • [signature-consistency] internal/cli/run.go:1976setupStatusNotifier now accepts role instead of agentName, but internally calls resolveRole(role). If h.Role from the harness is already canonical, this double-resolution is harmless but semantically unclear. A doc comment clarifying whether the parameter expects a raw or canonical role name would help future maintainers.

Previous run (5)

Review

Findings

High

  • [protected-path] .github/workflows/reusable-{code,fix,prioritize,retro,review,triage}.yml — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Human approval is required regardless of context.
    Remediation: Link an issue that documents authorization for this change, or obtain explicit human approval on the PR.

Low

  • [input-contract-documentation] action.yml:41 — The mint-url input description reads "Mint service URL for on-demand status comment tokens." With this PR, --mint-url is decoupled from the status notification block and now also drives agent token minting via mintAgentToken(). The description should reflect the broader scope.
    Remediation: Update the mint-url input description to note it is used for both status comment tokens and agent runtime tokens.
Previous run (6)

Review

Findings

High

  • [protected-path] .github/workflows/reusable-{code,fix,prioritize,retro,review,triage}.yml — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Human approval is required regardless of context.
    Remediation: Link an issue that documents authorization for this change, or obtain explicit human approval on the PR.

Low

  • [stale-doc] docs/ADRs/0049-agent-configuration-env-var-convention.md:65 — References FIX_GH_TOKEN as an example of an existing credential var with an agent-name prefix. This token pattern is being removed from workflows by this PR in favor of binary-based minting.
    Remediation: Update the example to use a current credential var pattern, or note that prefixed *_GH_TOKEN vars are deprecated.

  • [stale-doc] docs/superpowers/plans/2026-05-04-retro-agent.md:847 — Shows RETRO_GH_TOKEN in a workflow setup-agent-env step example. This token is removed from workflows by this PR. As a plan document, the operational risk is low.

  • [stale-doc] docs/guides/user/customizing-agents.md:44 — Shows PUSH_TOKEN in a runner_env example without noting that in CI, this value is auto-minted by the binary when --mint-url is provided.
    Remediation: Add a brief note that PUSH_TOKEN is auto-populated via mint in CI; manual values are only needed for local runs.


Labels: PR modifies token minting infrastructure, CI workflow files, and harness integration.

Previous run (7)

Review

Findings

High

  • [protected-path] .github/workflows/reusable-{code,fix,prioritize,retro,review,triage}.yml — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Human approval is required regardless of context.
    Remediation: Link an issue that documents authorization for this change, or obtain explicit human approval on the PR.

Medium

  • [scope-documentation-mismatch] docs/ADRs/0045-forge-portable-harness-schema.md — The PR body claims alignment with ADR-0045 but ADR-0045 covers harness schema portability (role/slug fields), not token minting. The change uses the role field introduced by ADR-0045 but implements a separate concern (token minting via the binary). ADR-0029 (Central token mint) is the more relevant ADR.
    Remediation: Update the PR description to cite ADR-0029 instead of or in addition to ADR-0045, and clarify the indirect connection.

  • [stale-doc] docs/plans/adr-0045-forge-portable-harness-phase2.md:129 — Phase 2 plan documents moving PUSH_TOKEN, PUSH_TOKEN_SOURCE, and REVIEW_TOKEN into forge.github.runner_env blocks. This PR takes a different approach — minting tokens in the binary via mintAgentToken() rather than moving them into harness YAML. The plan is now inconsistent with the implemented approach.
    Remediation: Update the plan to reflect that these tokens are auto-minted by the binary when --mint-url is provided, or mark the relevant section as superseded.

Low

  • [error-message-consistency] internal/cli/run.go:2071fmt.Errorf("invalid role %q: %w", canonicalRole, err) double-includes the role name since mintcore.ValidateRoleName already returns invalid role name "X". Compare with minttoken.go:59 which uses fmt.Errorf("invalid role: %w", err).

  • [naming-consistency] internal/cli/run.go — Inconsistent variable naming for canonical role: canonicalRole in mintAgentToken() vs canonRole in setupStatusNotifier(). The codebase pattern in minttoken.go:57 is to shadow the parameter: role = resolveRole(role).

  • [token-masking-gap] internal/cli/run.go:1956 — In setupStatusNotifier's client factory, when mintTokenPattern does not match result.Token, the code skips ::add-mask:: but still uses the token. By contrast, the new mintAgentToken correctly returns an error when the pattern doesn't match. See also: [token-masking-gap] finding at reconcilestatus.go:74.

  • [token-masking-gap] internal/cli/reconcilestatus.go:74 — Same pattern as run.go:1956 — when mintTokenPattern does not match, the token is used without masking and without returning an error.

  • [error-handling-gaps] internal/cli/run.go — When mintURL is empty and h.Role is non-empty, mintAgentToken returns (false, nil) and the caller prints a StepWarn. The warning text "skipping token minting" could mislead operators — downstream ValidateRunnerEnvWith will catch the missing tokens, but the warning doesn't indicate the run will fail.

  • [struct-naming] internal/cli/run.go:2044tokenVar doesn't communicate that these are environment variable specifications for roles. Existing patterns use descriptive suffixes (e.g., fetchServiceEnv, statusOpts).

  • [stale-doc] docs/superpowers/plans/2026-05-04-retro-agent.md:847 — The retro agent implementation plan shows a workflow snippet with RETRO_GH_TOKEN as an env var. This reflects the old workflow-passthrough token model which this PR replaces with binary-based minting.

  • [stale-doc] docs/guides/user/customizing-agents.md:44 — Guide shows PUSH_TOKEN in runner_env example. While the harness still uses this variable (the binary sets it before env expansion), the example could note that the value is auto-populated via mint in CI.

  • [api-shape] internal/cli/run.gomintAgentToken returns (bool, func(), error). The bool minted is used at the call site (if !minted && mintURL == ""), but the return signature differs from comparable functions like setupFetchService which uses a typed first return value.


Labels: PR modifies token minting infrastructure, CI workflow files, and CLI run command

Previous run (8)

Review

Findings

High

  • [protected-path] .github/workflows/reusable-{code,fix,prioritize,retro,review,triage}.yml — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Human approval is required regardless of context.
    Remediation: Link an issue that documents authorization for this change, or obtain explicit human approval on the PR.

Medium

  • [dead-code] internal/cli/run.goroleTokenVars maps the "retro" role to [{Name: "RETRO_SANDBOX_TOKEN"}], but RETRO_SANDBOX_TOKEN is not referenced anywhere in the codebase — not in the retro harness (harness/retro.yaml), not in env/retro.env, not in scripts/post-retro.sh, and not in any workflow. The retro harness's forge.github.runner_env uses GH_TOKEN (already set unconditionally by mintAgentToken). This dead mapping sets an env var that nothing reads.
    Remediation: Remove the "retro" entry from roleTokenVars, since the retro role only needs GH_TOKEN.

  • [scope-documentation-mismatch] docs/ADRs/0045-forge-portable-harness-schema.md — The PR body claims alignment with ADR-0045 and describes adding mintAgentToken(). However, ADR-0045 covers harness schema portability (role/slug/base/forge fields), not token minting. The ADR does not mention token minting, PUSH_TOKEN removal, or binary-side token acquisition. The PR description conflates harness identity (what ADR-0045 covers) with credential acquisition architecture.
    Remediation: Clarify in the PR description that this PR uses the role field introduced by ADR-0045 but implements a separate concern (token minting). Consider a separate ADR for the token minting architecture change.

Low

  • [workflow-command-injection] internal/cli/run.go:1956 — In setupStatusNotifier's client factory, the ::add-mask:: emission is guarded by mintTokenPattern.MatchString(result.Token). If the pattern does NOT match, the token is silently used without masking and will appear unmasked in GHA logs. Compare to minttoken.go which correctly rejects non-matching tokens with an error. See also: [token-masking-gap] finding at reconcilestatus.go:74.

  • [token-masking-gap] internal/cli/reconcilestatus.go:74 — Same pattern as run.go:1956 — when mintTokenPattern does not match, the token is used without masking and without returning an error. Inconsistent with the stricter validation in minttoken.go.

  • [error-handling-gaps] internal/cli/run.go — When mintURL is empty and h.Role is non-empty, mintAgentToken returns (false, nil) and the caller prints a StepWarn. The agent proceeds and will fail at ValidateRunnerEnvWith because GH_TOKEN and role-specific vars will not be set. The system fails safely (validation catches it), but the warning text "skipping token minting" could mislead operators into thinking minting is optional when in CI it is required.

  • [stale-doc] docs/superpowers/plans/2026-05-04-retro-agent.md:847 — The retro agent implementation plan shows a workflow snippet with RETRO_GH_TOKEN as an env var. This reflects the old workflow-passthrough token model which this PR replaces with binary-based minting. As a planning document, the operational risk is low.


Labels: PR modifies token minting infrastructure, CI workflows, and harness integration

Previous run (9)

Review

Findings

High

  • [protected-path] .github/workflows/reusable-{code,fix,prioritize,retro,review,triage}.yml — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Human approval is required regardless of context.
    Remediation: Link an issue that documents authorization for this change, or obtain explicit human approval on the PR.

Medium

  • [dead-code] internal/cli/run.go:2063roleTokenVars maps the "retro" role to [{Name: "RETRO_SANDBOX_TOKEN"}], but RETRO_SANDBOX_TOKEN is not referenced anywhere in the codebase — not in the retro harness (harness/retro.yaml), not in env/retro.env, not in scripts/post-retro.sh, and not in any workflow. The retro harness's forge.github.runner_env uses GH_TOKEN (already set unconditionally by mintAgentToken for all roles). This dead mapping sets an env var that nothing reads, which is harmless but misleading for future maintainers.
    Remediation: Remove the "retro" entry from roleTokenVars, since the retro role only needs GH_TOKEN.

  • [scope-mismatch] docs/ADRs/0045-forge-portable-harness-schema.md — The PR body claims this implements ADR-0045 and describes adding mintAgentToken(). However, ADR-0045 is about harness schema portability (role/slug/base/forge: fields), not token minting. The ADR does not mention token minting, PUSH_TOKEN removal, or binary-side token acquisition. The PR description conflates harness identity (what ADR-0045 covers) with credential acquisition architecture.
    Remediation: Create a separate ADR for token minting changes, or amend ADR-0045 to include token minting in scope. Update the PR description to reference the correct ADR.

Low

  • [error-handling-gaps] internal/cli/run.go:315 — When mintURL is empty and h.Role is non-empty, mintAgentToken returns (false, nil) and the caller prints a StepWarn. The agent proceeds and will fail at ValidateRunnerEnvWith because GH_TOKEN and role-specific vars will not be set. The system fails safely (validation catches it), but the warning text "skipping token minting" could mislead operators into thinking minting is optional when in CI it is required.

  • [workflow-command-injection] internal/cli/run.go:1956 — In setupStatusNotifier's client factory, the ::add-mask:: emission is guarded by mintTokenPattern.MatchString(result.Token). If the pattern does NOT match, the token is silently used without masking and will appear unmasked in logs. The minttoken.go command takes the safer approach of returning an error when the pattern doesn't match, while the status notifier silently proceeds.

  • [token-masking-gap] internal/cli/reconcilestatus.go:74 — Same pattern as run.go:1956 — when mintTokenPattern does not match, the token is used without masking and without returning an error. Inconsistent with the stricter validation in minttoken.go.

  • [function-signature] internal/cli/run.gomintAgentToken returns (bool, func(), error) which is inconsistent with the established cleanup pattern. Compare with setupFetchService which returns (fetchServiceEnv, func(), error) with a typed result. A named return or typed result struct would improve clarity.

  • [stale-workflow-pattern] docs/superpowers/plans/2026-05-04-retro-agent.md:847 — The retro agent implementation plan shows a workflow snippet with RETRO_GH_TOKEN as an env var. This reflects the old workflow-passthrough token model which this PR replaces with binary-based minting. As a planning document, the operational risk of this staleness is low.

  • [stale-doc] docs/ADRs/0049-agent-configuration-env-var-convention.md:65 — Uses FIX_GH_TOKEN as an example of an existing credential var. This PR removes FIX_GH_TOKEN from workflows (now minted by the binary via --mint-url instead of passed through workflows).

  • [stale-doc] docs/plans/adr-0045-forge-portable-harness-phase2.md:129 — Phase 2 plan references PUSH_TOKEN, PUSH_TOKEN_SOURCE, and REVIEW_TOKEN as env vars to move to forge.github.runner_env. This PR changes how these vars are populated — they're no longer passed from workflows but minted by the binary when --mint-url is provided.

Previous run (10)

Review

Findings

High

  • [protected-path] .github/workflows/reusable-{code,fix,prioritize,retro,review,triage}.yml — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Human approval is required regardless of context.
    Remediation: Link an issue that documents authorization for this change, or obtain explicit human approval on the PR.

Low

  • [error-handling-gaps] internal/cli/run.go:315 — When mintURL is empty and h.Role is non-empty, mintAgentToken returns (false, nil) and the caller prints a StepWarn. The agent proceeds and will fail at ValidateRunnerEnvWith because GH_TOKEN and role-specific vars will not be set. The system fails safely (validation catches it), but the warning text "skipping token minting" could mislead operators into thinking minting is optional when in CI it is required.

  • [GHA-workflow-command-injection] internal/cli/run.goExpiresAt field from the mint service response is sanitized via strings.Map allowlist (digits, -:TZ+), which effectively prevents :: injection. Token is validated against mintTokenPattern before ::add-mask::, preventing workflow command injection through the token value. Residual risk is negligible.

  • [stale-workflow-pattern] docs/superpowers/plans/2026-05-04-retro-agent.md:847 — The retro agent implementation plan shows a workflow snippet with RETRO_GH_TOKEN as an env var. This reflects the old workflow-passthrough token model which this PR replaces with binary-based minting. As a planning document, the operational risk of this staleness is low.

Info

  • [permission-reduction] .github/workflows/reusable-*.yml — Removal of CODE_GH_TOKEN, FIX_GH_TOKEN, PUSH_TOKEN, PUSH_TOKEN_SOURCE, REVIEW_TOKEN, RETRO_SANDBOX_TOKEN, and GH_TOKEN env var passthrough from 6 workflow files reduces the surface of token exposure. Positive security improvement.

  • [secrets-handling] internal/cli/run.go — The new mintAgentToken correctly masks the minted token via ::add-mask:: before setting env vars. Token is validated against mintTokenPattern before masking, preventing workflow command injection through the token value.

  • [migration-path-unclear] — The PR body references ADR-0045 but doesn't clarify which phase this PR represents, and whether the dual-state (workflows AND binary both minting tokens) is intentional transitional architecture.

Previous run (11)

Review

Findings

High

  • [protected-path] .github/workflows/reusable-{code,fix,prioritize,retro,review,triage}.yml — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Human approval is required regardless of context.
    Remediation: Link an issue that documents authorization for this change, or obtain explicit human approval on the PR.

Medium

  • [test-integrity] internal/cli/run_test.gomintAgentToken calls os.Setenv for GH_TOKEN, PUSH_TOKEN, PUSH_TOKEN_SOURCE, REVIEW_TOKEN, and RETRO_SANDBOX_TOKEN inside the function under test. These mutations are NOT managed by t.Setenv and persist across tests, creating ordering dependencies between test functions.

  • [scope-coherence] internal/cli/run.gosetupStatusNotifier (existing code) uses resolveRole(agentName) to derive the role from the agent name, while the new mintAgentToken receives h.Role from the harness. This creates an inconsistency: two call sites in runAgent derive the canonical role differently.

  • [stale-token-reference] docs/architecture.md:602 — The architecture document's 'MVP embodiment' section references PUSH_TOKEN in the context of post-script credential handling. While the env var name is unchanged, the token source has changed from workflow passthrough to binary-based minting.

Low

  • [error-handling-gaps] internal/cli/run.go:310 — When mintURL is empty and h.Role is non-empty, mintAgentToken returns (false, nil) and the caller prints a StepWarn. The agent still proceeds and will fail later at ValidateRunnerEnvWith. The added warning partially addresses the prior finding, and downstream env validation provides a hard stop with a clear error.

  • [GHA-workflow-command-injection] internal/cli/run.goExpiresAt field from the mint service response is sanitized via strings.Map allowlist (digits, -:TZ+), which effectively prevents :: injection. Lipgloss ANSI wrapping provides a secondary defense. Residual risk is negligible.

  • [stale-token-reference] docs/ADRs/0032-safe-push-wrapper-for-sandboxed-agents.md:159 — ADR 0032 references PUSH_TOKEN in the context of Tier 1 post-script push. As an ADR (historical record), the reference is still conceptually correct — the post-script still uses a push token, now minted by the binary rather than passed from the workflow.

Info

  • [permission-reduction] .github/workflows/reusable-*.yml — Removal of CODE_GH_TOKEN, PUSH_TOKEN, PUSH_TOKEN_SOURCE, REVIEW_TOKEN, RETRO_SANDBOX_TOKEN, and GH_TOKEN env var passthrough from 6 workflow files reduces the surface of token exposure. Positive security improvement.

  • [secrets-handling] internal/cli/run.go — The new mintAgentToken correctly masks the minted token via ::add-mask:: before setting env vars. Token is validated against mintTokenPattern before masking, preventing workflow command injection through the token value.

Previous run (12)

Review

Findings

High

  • [protected-path] .github/workflows/reusable-{code,fix,prioritize,retro,review,triage}.yml — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Human approval is required regardless of context.
    Remediation: Link an issue that documents authorization for this change, or obtain explicit human approval on the PR.

Low

  • [error-handling-gaps] internal/cli/run.go:310mintAgentToken returns (false, nil) when mintURL is empty, and the boolean is discarded by the caller in runAgent. If mint-url is accidentally omitted in CI, minting silently does nothing and the agent proceeds without tokens, failing later at env validation or with a 401. A warning log when minting is skipped despite a non-empty harness role would aid debugging.

  • [GHA-workflow-command-injection] internal/cli/run.goExpiresAt field from the mint service response is interpolated into printer.StepDone output without sanitization. Lipgloss ANSI wrapping currently prevents GHA from parsing :: commands, but if NO_COLOR=1 is set and the mint service is compromised, ExpiresAt could theoretically inject workflow commands. The token itself is properly validated against mintTokenPattern before use in ::add-mask::.

Info

  • [naming-convention] internal/cli/run.goroleTokenVars could be more explicit as roleTokenEnvVars to match the naming pattern of similar environment variable maps in the codebase (e.g., trafficEnvVars, verifyEnvVars).

  • [test-adequacy] internal/cli/run_test.gomintAgentToken tests set env vars via os.Setenv inside the function under test (GH_TOKEN, PUSH_TOKEN, etc.) but do not restore them. t.Setenv only manages variables explicitly registered with it, so these side effects leak between tests, creating ordering dependencies.

  • [permission-reduction] .github/workflows/reusable-*.yml — Removal of CODE_GH_TOKEN, PUSH_TOKEN, PUSH_TOKEN_SOURCE, REVIEW_TOKEN, RETRO_SANDBOX_TOKEN, and GH_TOKEN env var passthrough from 6 workflow files reduces the surface of token exposure in workflow logs and step environments. Positive security improvement.

Previous run (13)

Review

Findings

High

  • [protected-path] .github/workflows/reusable-{code,fix,prioritize,retro,review,triage}.yml — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Human approval is required regardless of context.

Medium

  • [input-validation] internal/cli/run.goresolveMintRepos() accepts repo names from MINT_REPOS and REPO_FULL_NAME environment variables without validating them against mintcore.RepoNamePattern. The existing mint token CLI command at minttoken.go:52 validates each repo name with this pattern. Unvalidated repo names are sent to the mint service.
    Remediation: Add mintcore.RepoNamePattern.MatchString() validation for each resolved repo name in resolveMintRepos(), matching the validation in minttoken.go.

  • [stale-reference] docs/guides/user/running-agents-locally.md:149 — Documentation references REVIEW_TOKEN environment variable. While this remains valid for local runs (no mint service), the guide should note that in CI, tokens are now automatically minted by the binary when --mint-url is provided.
    Remediation: Add a note to the review agent section about automatic token minting in CI.

  • [stale-reference] docs/guides/user/running-agents-locally.md:170 — Documentation references PUSH_TOKEN and PUSH_TOKEN_SOURCE for the code agent. Same situation: still valid for local runs but incomplete without noting CI auto-minting.
    Remediation: Update the code agent section to mention the new token minting mechanism in CI.

Low

  • [dead-code] internal/cli/run.goroleTokenVars["retro"] sets RETRO_SANDBOX_TOKEN, but no harness YAML or script references this variable. The retro harness (retro.yaml) uses GH_TOKEN, which is already set unconditionally by mintAgentToken. Setting RETRO_SANDBOX_TOKEN has no effect.

  • [input-validation] internal/cli/run.gomintAgentToken does not call mintcore.ValidateRoleName(canonicalRole) before passing the role to the mint service, unlike the mint token CLI command at minttoken.go:58. Server-side validation exists but client-side validation provides better error messages and consistency.

  • [pattern-inconsistency] internal/cli/run.goPUSH_TOKEN_SOURCE special-case handling via string equality check (if v == "PUSH_TOKEN_SOURCE") is a minor code smell. A constant or struct type would make the behavior self-documenting.

  • [doc-style] internal/cli/run.goroleTokenVars and mintAgentToken lack godoc comments. Most helpers in this file have godoc comments.

  • [stale-reference] docs/superpowers/plans/2026-05-04-retro-agent.md:194 — Plan doc references GH_TOKEN in env template. While GH_TOKEN is still the correct variable name, the token source has changed.

  • [stale-reference] docs/guides/user/customizing-agents.md:44 — Guide shows PUSH_TOKEN in runner_env example. The harness config still uses this variable, so the example is technically correct, but could note that the value is now auto-populated via mint in CI.

  • [stale-reference] docs/plans/adr-0045-forge-portable-harness-phase2.md:129 — Phase 2 plan references PUSH_TOKEN and PUSH_TOKEN_SOURCE in forge.github.runner_env migration context.

  • [stale-reference] docs/plans/adr-0045-forge-portable-harness-phase2.md:135 — Phase 2 plan references REVIEW_TOKEN in forge.github.runner_env migration context.

Info

  • [permission-reduction] .github/workflows/reusable-*.yml — Removal of *_GH_TOKEN, PUSH_TOKEN, PUSH_TOKEN_SOURCE, REVIEW_TOKEN, RETRO_SANDBOX_TOKEN, and GH_TOKEN env var passthrough from 6 workflow files reduces the surface of token exposure in workflow logs and step environments. Positive security improvement.

  • [naming-convention] internal/cli/run.goroleTokenVars could be more explicit as roleTokenEnvVars to clarify these are environment variable names.

  • [potential-update-needed] docs/ADRs/0032-safe-push-wrapper-for-sandboxed-agents.md:157 — ADR references PUSH_TOKEN used by post-script. Still functionally accurate but token source has changed.

  • [potential-update-needed] docs/architecture.md:602 — Architecture doc mentions PUSH_TOKEN in post-code.sh context. Functionally accurate but source changed.

Previous run (14)

Review

Findings

High

  • [protected-path] .github/workflows/reusable-{code,fix,prioritize,retro,review,triage}.yml — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Human approval is required regardless of context.

Medium

  • [input-validation] internal/cli/run.goresolveMintRepos() accepts repo names from MINT_REPOS and REPO_FULL_NAME environment variables without validating them against mintcore.RepoNamePattern. The existing mint token CLI command at minttoken.go:52 validates each repo name with this pattern. Unvalidated repo names are sent to the mint service.
    Remediation: Add mintcore.RepoNamePattern.MatchString() validation for each resolved repo name in resolveMintRepos(), matching the validation in minttoken.go.

  • [stale-reference] docs/guides/user/running-agents-locally.md:149 — Documentation references REVIEW_TOKEN environment variable. While this remains valid for local runs (no mint service), the guide should note that in CI, tokens are now automatically minted by the binary when --mint-url is provided.
    Remediation: Add a note to the review agent section about automatic token minting in CI.

  • [stale-reference] docs/guides/user/running-agents-locally.md:170 — Documentation references PUSH_TOKEN and PUSH_TOKEN_SOURCE for the code agent. Same situation: still valid for local runs but incomplete without noting CI auto-minting.
    Remediation: Update the code agent section to mention the new token minting mechanism in CI.

Low

  • [dead-code] internal/cli/run.goroleTokenVars["retro"] sets RETRO_SANDBOX_TOKEN, but no harness YAML or script references this variable. The retro harness (retro.yaml) uses GH_TOKEN, which is already set unconditionally by mintAgentToken. Setting RETRO_SANDBOX_TOKEN has no effect.

  • [input-validation] internal/cli/run.gomintAgentToken does not call mintcore.ValidateRoleName(canonicalRole) before passing the role to the mint service, unlike the mint token CLI command at minttoken.go:58. Server-side validation exists but client-side validation provides better error messages and consistency.

  • [pattern-inconsistency] internal/cli/run.goPUSH_TOKEN_SOURCE special-case handling via string equality check (if v == "PUSH_TOKEN_SOURCE") is a minor code smell. A constant or struct type would make the behavior self-documenting.

  • [doc-style] internal/cli/run.goroleTokenVars and mintAgentToken lack godoc comments. Most helpers in this file have godoc comments.

  • [stale-reference] docs/superpowers/plans/2026-05-04-retro-agent.md:194 — Plan doc references GH_TOKEN in env template. While GH_TOKEN is still the correct variable name, the token source has changed.

  • [stale-reference] docs/guides/user/customizing-agents.md:44 — Guide shows PUSH_TOKEN in runner_env example. The harness config still uses this variable, so the example is technically correct, but could note that the value is now auto-populated via mint in CI.

  • [stale-reference] docs/plans/adr-0045-forge-portable-harness-phase2.md:129 — Phase 2 plan references PUSH_TOKEN and PUSH_TOKEN_SOURCE in forge.github.runner_env migration context.

  • [stale-reference] docs/plans/adr-0045-forge-portable-harness-phase2.md:135 — Phase 2 plan references REVIEW_TOKEN in forge.github.runner_env migration context.

Info

  • [permission-reduction] .github/workflows/reusable-*.yml — Removal of *_GH_TOKEN, PUSH_TOKEN, PUSH_TOKEN_SOURCE, REVIEW_TOKEN, RETRO_SANDBOX_TOKEN, and GH_TOKEN env var passthrough from 6 workflow files reduces the surface of token exposure in workflow logs and step environments. Positive security improvement.

  • [naming-convention] internal/cli/run.goroleTokenVars could be more explicit as roleTokenEnvVars to clarify these are environment variable names.

  • [potential-update-needed] docs/ADRs/0032-safe-push-wrapper-for-sandboxed-agents.md:157 — ADR references PUSH_TOKEN used by post-script. Still functionally accurate but token source has changed.

  • [potential-update-needed] docs/architecture.md:602 — Architecture doc mentions PUSH_TOKEN in post-code.sh context. Functionally accurate but source changed.

Previous run (15)

Review

Findings

Critical

  • [missing-environment-variable] .github/workflows/reusable-triage.yml:144 — The triage workflow passes mint-url to the composite action (line 154), which causes --mint-url to reach the binary. The binary's new mintAgentToken() calls resolveMintRepos(), which requires either MINT_REPOS or REPO_FULL_NAME in the process environment. The "Run triage agent" step env block (line 147) contains only GITHUB_ISSUE_URL — neither REPO_FULL_NAME nor MINT_REPOS is set. resolveMintRepos() will return an error, causing mintAgentToken to fail and the agent to crash.
    Remediation: Add REPO_FULL_NAME: ${{ inputs.source_repo }} to the "Run triage agent" env block.

  • [missing-environment-variable] .github/workflows/reusable-prioritize.yml:143 — The diff removes PRIORITIZE_GH_TOKEN from the setup-agent-env step (line 133), but the "Run prioritize agent" step (lines 143–150) does not pass mint-url in its with block. Without --mint-url and without FULLSEND_MINT_URL in the process environment, mintAgentToken() returns early as a no-op and GH_TOKEN is never set. The prioritize harness references ${GH_TOKEN} in runner_env, which will expand to empty. The agent will fail on any GitHub API call.
    Remediation: Add mint-url: ${{ inputs.mint_url }} to the "Run prioritize agent" with block, and add REPO_FULL_NAME: ${{ inputs.source_repo }} (or MINT_REPOS) to its env block.

High

  • [protected-path] .github/workflows/ — This PR modifies 6 files under .github/workflows/, which is a protected path requiring human approval. The PR has no linked issue providing justification for modifying governance/infrastructure files. Affected files: reusable-code.yml, reusable-fix.yml, reusable-prioritize.yml, reusable-retro.yml, reusable-review.yml, reusable-triage.yml.

Medium

  • [architectural-coherence] .github/workflows/reusable-*.yml — ADR-0029 ("Central token mint and shared apps for a secretless .fullsend") states that workflows obtain forge tokens from the mint when they need GitHub API access. This PR moves token minting into the binary, creating a different trust boundary. The PR references ADR-0045 but does not clarify how this relates to ADR-0029's workflow-level minting pattern.
    Remediation: Clarify whether this implements a variant of ADR-0029 or supersedes its workflow-level minting pattern, and update documentation accordingly.

Low

  • [missing-authorization] — This PR has no linked issue. Non-trivial changes to security boundary and credential flow benefit from explicit authorization.

  • [scope-alignment] .github/workflows/reusable-retro.yml — The PR adds a MINT_REPOS env var to reusable-retro.yml. While the PR body mentions it, the conditional logic mirrors the existing "Mint retro token" step at line 117. Consider updating the PR description to describe the behavioral mapping explicitly.

  • [token-validation] internal/cli/run.gomintAgentToken uses mintTokenPattern only for masking decisions, not for validation. Unlike minttoken.go which rejects tokens failing the pattern match, a malformed token from the mint service would be silently accepted. Defense-in-depth improvement.

  • [dead-code] internal/cli/run.go:1990roleTokenVars["retro"] sets RETRO_SANDBOX_TOKEN, but no harness YAML, script, or Go code reads this env var. The retro harness only uses GH_TOKEN in runner_env. The only prior consumer (the workflow env block) is removed by this PR.

  • [error-handling] internal/cli/run.go:2005 — Error wrapping format "resolving mint repos: %w" is less specific than the codebase pattern of including identifiers (e.g., "loading env file %s: %w").

Info

  • [permission-reduction] .github/workflows/reusable-*.yml — Removal of *_GH_TOKEN, PUSH_TOKEN, PUSH_TOKEN_SOURCE, and similar env vars from 6 workflow files reduces the surface of token exposure in workflow logs and step environments.

  • [phase-alignment] — The PR's use of h.Role to drive mint calls aligns with ADR-0045 Phase 2/3 intent but doesn't reference which phase it belongs to.

@fullsend-ai-review fullsend-ai-review Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the review comment for full details.

Comment thread internal/cli/run.go Outdated
Comment thread internal/cli/run.go Outdated
@fullsend-ai-review

fullsend-ai-review Bot commented Jun 17, 2026

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 3:25 PM UTC · Completed 3:39 PM UTC
Commit: a7f2e35 · View workflow run →

@fullsend-ai-review fullsend-ai-review Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the review comment for full details.

@fullsend-ai-review

fullsend-ai-review Bot commented Jun 17, 2026

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 3:51 PM UTC · Completed 4:06 PM UTC
Commit: 9e99539 · View workflow run →

@fullsend-ai-review fullsend-ai-review Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the review comment for full details.

Comment thread internal/cli/run.go
@fullsend-ai-review

fullsend-ai-review Bot commented Jun 17, 2026

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 4:17 PM UTC · Completed 4:35 PM UTC
Commit: 0d51413 · View workflow run →

@fullsend-ai-review fullsend-ai-review Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the review comment for full details.

Comment thread internal/cli/run.go
@fullsend-ai-review

fullsend-ai-review Bot commented Jun 17, 2026

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 4:46 PM UTC · Completed 5:01 PM UTC
Commit: 54ff8d5 · View workflow run →

@fullsend-ai-review fullsend-ai-review Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the review comment for full details.

Comment thread internal/cli/run.go
@rh-hemartin

Copy link
Copy Markdown
Member

Shouldn't you remove the mint-token step from the workflows as well? And also remove the action completely?

@waynesun09 waynesun09 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ADR-0045 Review Squad — 12 findings (medium+ severity). Reviewed for correctness, security, and ADR alignment.

Comment thread .github/workflows/reusable-prioritize.yml
Comment thread internal/cli/run.go
Comment thread internal/cli/run.go Outdated
Comment thread internal/cli/run.go
Comment thread internal/cli/run.go Outdated
Comment thread internal/cli/run.go
Comment thread internal/cli/run.go
Comment thread internal/cli/run.go
Comment thread internal/cli/run_test.go
Comment thread internal/cli/run.go
@fullsend-ai-review

fullsend-ai-review Bot commented Jun 22, 2026

Copy link
Copy Markdown

🤖 Finished Review · ❌ Failure · Started 3:50 PM UTC · Completed 4:08 PM UTC
Commit: e37f1b9 · View workflow run →

@ggallen

ggallen commented Jun 22, 2026

Copy link
Copy Markdown
Member Author

/fs-review

@fullsend-ai-review

fullsend-ai-review Bot commented Jun 22, 2026

Copy link
Copy Markdown

🤖 Finished Review · ❌ Failure · Started 4:20 PM UTC · Completed 4:34 PM UTC
Commit: 4e21a60 · View workflow run →

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: Greg Allen <gallen@redhat.com>
@fullsend-ai-review

fullsend-ai-review Bot commented Jun 23, 2026

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 12:02 PM UTC · Completed 12:18 PM UTC
Commit: 277e2b4 · View workflow run →

@fullsend-ai-review fullsend-ai-review Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the review comment for full details.

Comment thread action.yml
@waynesun09
waynesun09 added this pull request to the merge queue Jun 24, 2026
Merged via the queue into main with commit 9c3f8ee Jun 24, 2026
16 checks passed
@waynesun09
waynesun09 deleted the worktree-mint-in-binary branch June 24, 2026 14:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

component/ci CI pipelines and checks component/harness Agent harness, config, and skills loading component/mint Token mint and cross-boundary credentials type/feature New capability request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants