Commit activity
Last 12 weeks · 20 commits
Community health
2 of 6 standards met
62
✓README○License○Contributing✓Code of Conduct○Issue Template○PR Template
Recent PRs & issues
Active · 2 in progress · Last activity 4w ago
See all on GitHub →
What Following on #16, lean on Flue and pi-ai to detect LLM providers, allowing users to supply an OpenAI API key. This enables support for GPT models. Why Given the popularity of OpenAI models and Codex for software development, it stands to reason that there will be user demand for support for GPT models, alongside Cloudflare Workers AI and Anthropic ones. This PR seeks to anticipate that demand. How it works The action is dependent on Flue and thus pi. Similar to #16, we lean on pi's auto-detection of OpenAI credentials[^1] to interact with GPT models. Changes — added — added — sets whichever of when provided, along with the check for any of Cloudflare, OpenAI, or Cloudflare credentials README.md** — documented the new input. — rebuilt. Usage [^1]: https://pi.dev/docs/latest/providers#api-keys
Summary Two security concerns after reviewing the action — related to the recent disclosure about AI coding agents being compromised through GitHub issues. 1. 🔴 Long-lived tokens in CI (no OIDC) File: and are long-lived personal tokens. If the workflow is compromised (e.g., via a malicious PR modifying the workflow file), these tokens can be exfiltrated and reused indefinitely. Recommendation: Use OIDC (GitHub Actions → AWS STS / GCP Workload Identity) for cloud access, and GitHub App installation tokens (short-lived, scoped to the repo) instead of personal access tokens. Ref: Brikman "Fundamentals of DevOps", ch.5 — "Never use long-lived tokens in CI. OIDC provides temporary credentials that expire in minutes." 2. 🟡 Prompt injection via issue body The triage bot reads and passes it to Claude via Flue subagents. Per the Aug 7 disclosure, attackers can craft issues containing prompt injections: The reproduce subagent would see this, and if it reaches the fix step, the fix subagent might follow the injected instructions. Current mitigations (good!): ✓ ✓ Subagent context isolation ✓ No ✓ Additional suggestions: Strip or sanitize before passing to the first subagent (remove text matching "ignore previous instructions", "you are now", etc.) Prefix the issue body with a clear boundary: and instruct the agent to NEVER follow instructions inside `` Add a canary check: before pushing any fix, validate the diff against known injection patterns Both findings are from an automated security scan using GSC (Git Security Checker) — an AppSec platform for AI-agent pipelines. Happy to provide more detail or a PR if helpful!
Recent fixes
What Adds Cloudflare Workers AI (e.g. Kimi) as an alternative to Anthropic for the triage pipeline, so repos without an Anthropic token can run the bot. Why The Astro compiler repo wants to enable auto-triage but doesn't have access to the Anthropic token (it's set up directly with Anthropic by an individual, not through Cloudflare). We already have Workers AI access, so this lets that repo point the bot at a Kimi model instead. How it works The action never calls Anthropic directly — it goes through Flue → pi-ai. pi-ai already ships a built-in provider that uses the OpenAI-compatible REST endpoint () with a bearer token. That's a plain HTTPS call — no Worker deployment, no , no bindings. The action still runs on the standard GitHub Actions runner, exactly like it does for Anthropic today. / were already arbitrary inputs, so the only missing piece was wiring the credentials. Changes — is now optional; added and . — nullable; added the two Cloudflare fields. — sets whichever of / / are provided; guards that either an Anthropic key or a full Cloudflare pair is present (and that a CF key isn't set without an account ID). — documented the new inputs and added a Workers AI / Kimi usage example. — rebuilt. Usage Testing , , and all pass (41 tests, 0 failures). Note Kimi via Workers AI is OpenAI-completions-style without Anthropic-grade prompt caching / tool-calling fidelity, so quality and latency on the agentic triage pipeline will differ from Opus/Sonnet. This is opt-in per repo via the model inputs, not a change to the defaults.
I needed this feature because in the compiler-rs we don't need a preview release, followed by a confirmation of the fix. In the compiler a test and integration test are enough to validate the fix. [!NOTE] AI generated When auto-pr-on-fix is enabled, triage opens a PR immediately after it finds and pushes a fix, skipping the preview/reporter-confirmation flow and moving the issue straight to 'fix verified'. This unblocks repos that can't publish pkg.pr.new previews (e.g. non-npm projects), where a found fix previously fell back to 'needs triage' and no PR was created. action.yml/context/index: new auto-pr-on-fix input (default false) src/pr.ts: shared PR-body generators extracted from verify-fix triage: direct-PR path (idempotent via findPullRequest) + PR link in the issue comment; resolveTriageLabel returns fixVerified when a PR was opened tests: unit coverage for resolveTriageLabel and a mocked auto-PR flow rebuilt dist/
Problem When the triage bot commits an agent's fix, it built a shell command via git commit -m ${JSON.stringify(commitMessage)}\. only produces a double-quoted JS string literal — it does not escape backticks or , which are command substitution inside a double-quoted shell string. LLM-authored commit messages routinely contain backticks (e.g. `removeTrailingForwardSlash('/')/bin/shisPushedforce: truemainpkg.pr.newgitCommit()src/github.tsexecFilegitPushfailed('/')$(whoami)"quotes"mainpnpm testcheck:distpnpm lintpnpm formatdist/dist/git commit -m ""` shell string is gone from the bundle.
Structured data for AI agents
Repository: withastro/triagebot-action. Description: A GitHub Action for issue triage Stars: 187, Forks: 15. Primary language: TypeScript. Languages: TypeScript (99.6%), JavaScript (0.4%). Open PRs: 2, open issues: 1. Last activity: 4w ago. Community health: 62%. Top contributors: matthewp, ematipico.