feat: code agent automation layer

[ben-alkov]

Summary

• Adds 5 new forge.Client methods for issue labels, comments, and PR lookup/creation (prep commit)
• Implements fullsend entrypoint code — the deterministic Go wrapper that orchestrates the code agent lifecycle (env parsing, git setup, code agent, commit check, secret scan, optional pre-push review, push, draft PR, label swap)
• Graceful degradation when agents/review.md is absent; token isolation ensures bot credentials never enter the agent's environment

Addresses task #3 from the sync-up on #127, assigned to @ben-alkov.

Test plan

• 30 new tests across 4 packages (258 total pass)
• go vet ./... clean
• pre-commit clean
• Review forge method implementations against GitHub API docs
• Verify composite action compatibility (fullsend entrypoint code --scm github)

[ralphbean]

The e2e failure here is expected — GitHub does not expose secrets to pull_request workflows from forks. Tracked in #209.

[ben-alkov]

Review: #208

Head SHA: 794047d4a95833ff05317206a464fc7d546b69e2
Timestamp: 2026-04-09T16:30:00Z
Outcome: request-changes

Summary

The PR implements the authorized automation layer (issue #127 task #3) correctly in structure and intent. Token isolation is substantially sound — the bot token is stripped from the agent environment via SanitizeEnv. However, two findings require resolution. First, several GHA runner environment variables (GITHUB_ENV, GITHUB_OUTPUT, GITHUB_PATH, ACTIONS_RUNTIME_TOKEN, ACTIONS_CACHE_URL) pass through SanitizeEnv unchanged; a prompt-injected code agent could write to GITHUB_ENV/GITHUB_OUTPUT to inject variables into subsequent pipeline steps. Second, the commit-detection logic treats any non-zero git diff --quiet exit as "commits exist," meaning exit 128 (infrastructure error) would let the pipeline proceed past the commit check on a branch with no agent-produced changes.

Findings

High

• [content-security / token-leakage-via-gha-sinks] internal/entrypoint/runner.go:40-65 — SanitizeEnv removes FULLSEND_*, GITHUB_TOKEN, and GH_TOKEN, but does not strip GITHUB_ENV, GITHUB_OUTPUT, GITHUB_PATH, GITHUB_STEP_SUMMARY, ACTIONS_RUNTIME_TOKEN, or ACTIONS_CACHE_URL. These are file paths and tokens that GHA watches: any process that appends KEY=VALUE to the file at GITHUB_ENV injects that variable into every subsequent step in the same job. ACTIONS_RUNTIME_TOKEN grants access to the GHA artifact and cache APIs.
  Remediation: Extend the deny list to include GITHUB_ENV, GITHUB_OUTPUT, GITHUB_PATH, GITHUB_STEP_SUMMARY, GITHUB_STATE, ACTIONS_RUNTIME_TOKEN, ACTIONS_CACHE_URL, and add a deny prefix ACTIONS_. Alternatively, invert to an allowlist of explicitly safe variables (PATH, HOME, LANG, TERM, TMPDIR).

• [logic-error / false-positive-commit-detection] internal/entrypoint/code.go:113-120 — git diff --quiet exit code != 0 is interpreted as "commits exist," but exit 128 indicates a git infrastructure error (bad ref, corrupt repo). This would let the pipeline proceed to secret scan and push with no agent commits.
  Remediation: Check specifically for exit code 1 as "has commits." Treat any other non-zero code as an infrastructure failure:

  switch diffCode {
  case 0:
      // no commits
  case 1:
      // has commits, proceed
  default:
      return nil, fmt.Errorf("git diff exited %d", diffCode)
  }

Medium

• [data-exposure / credential-at-rest] internal/entrypoint/code.go:159-170 — git remote set-url origin https://x-access-token:<token>@github.com/... writes the bot token into .git/config. After push, the token persists on disk. GHA ephemeral runners mitigate this, but it is unnecessary residual risk.
  Remediation: After push, reset the remote URL to the non-authenticated form, or use git push https://x-access-token:<token>@... HEAD:<branch> as a one-shot argument.

• [observability / silent-stderr] internal/entrypoint/runner.go:29-31 — ExecRunner captures stderr into a buffer that is never used. When commands fail, operators get only the exit code with no diagnostic content.
  Remediation: Include stderr.String() in the error for non-zero exits.

• [missing-test / token-isolation] internal/entrypoint/code_test.go — No test verifies that the safeEnv slice passed to the claude runner excludes env.BotToken. SanitizeEnv is tested in isolation, but RunCode tests pass nil for safeEnv.
  Remediation: Add a test that constructs a dirty environment and asserts the agent runner call's Env field excludes bot token and GITHUB_TOKEN.

Low

• [style / misleading-description] internal/cli/entrypoint.go:36 — Long description says "Clones the repo" but RunCode expects a pre-cloned workspace (env.Workspace).
  Remediation: Change to "Runs the code agent against a pre-checked-out workspace, validates output, and opens a PR."

Info

• [intent-alignment] The PR implements task #3 from the sync-up on #127. Scope matches authorization. CI-failure retry and dispatch routing are correctly deferred to Story 9 and Story 2 respectively.
• [injection-defense] No non-rendering Unicode found in PR body, commit messages, or code. Agent prompt strings embed only integer issue numbers and internal branch/ref names — no untrusted user content reaches prompt strings at the automation layer.

Footer

Outcome: request-changes
This review applies to SHA 794047d4a95833ff05317206a464fc7d546b69e2. Any push to the PR head clears this review and requires a new evaluation.

[ben-alkov]

The preceding is from the review agent in PR #171.

It had a pertinent note, and a summary of the review as a test:

Review posted to #208. Had to use --comment instead of --request-changes since you're the PR author — GitHub doesn't allow requesting changes on your own PR.

The skill pipeline worked end to end: pr-review loaded, delegated evaluation to code-review (via the review subagent), I ran PR-specific checks (body injection, commit message injection, scope authorization), and posted. The SanitizeEnv gap and the git diff exit-code issue are the two high findings worth addressing.

[maruiz93]

I believe this overlaps with #231

I think that if my PR is merged this should probably be refactored into:

• pre-scripts for the git setup
• validation scan for the scan of the output
• post-script for the gh push

Then, for the rest of the gh integration it should be probably keep being integrated in the fullsend cli, and in a way it's used with the run command.

Also, the review agent could be a separate agent with its own harness in the "framework" I defined.

[github-actions]

Site preview

Preview: https://b01bcb31-site.fullsend-ai.workers.dev

Commit: 45266413fe4b0fdcebbd936359bc95e2e9b8ada4

[ralphbean]

Closing with a link to #286 after discussion in slack.