feat(ci): Add Flue issue triage hook

[dcramer]

Add a GitHub Actions-backed Flue hook for newly opened GitHub issues.

The hook runs as a CLI-only Flue agent on issues.opened. It uses one cohesive issue-triage skill with deterministic stages: duplicate search, duplicate closure, repository preparation, diagnosis/validation, and issue update.

The TypeScript handler fetches a fresh trusted context snapshot before each model stage. That context includes the current issue, existing repository labels, repository name, and prior structured results, while Valibot schemas constrain each stage output. This keeps judgment in the skill but leaves GitHub reads, stage routing, and mutation gates in deterministic code.

GitHub Actions is the first deployment target because these are GitHub issue events: it avoids a hosted webhook endpoint, uses the built-in GITHUB_TOKEN with issues: write, and lets the agent inspect the checked-out repository through Flue local sandbox. The docs also call out Cloudflare as the likely next target for external webhooks.

Reviewers should look closely at the issue mutation behavior, duplicate-closing threshold, and prompt-injection guardrails around untrusted issue content.

[semgrep-code-getsentry]

High severity vulnerability may affect your project—review required:
Line 3818 lists a dependency (fast-xml-parser) with a known High severity vulnerability.

ℹ️ Why this matters

Affected versions of fast-xml-parser are vulnerable to Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion'). The replaceEntitiesValue() function processes numeric character references (&#NNN; and &#xHH;) through a separate code path that has no expansion limit tracking, allowing an attacker to bypass all configured processEntities limits by supplying XML with a large number of numeric entity references, causing excessive memory consumption and CPU usage.

References: GHSA, CVE

To resolve this comment:
Check if you are using fxparser on the CLI.

• If you're affected, upgrade this dependency to at least version 5.5.6 at pnpm-lock.yaml.
• If you're not affected, comment /fp we don't use this [condition]

💬 Ignore this finding

To ignore this, reply with:

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

_{You can view more details on this finding in the Semgrep AppSec Platform here.}

[semgrep-code-getsentry]

High severity vulnerability may affect your project—review required:
Line 3818 lists a dependency (fast-xml-parser) with a known High severity vulnerability.

ℹ️ Why this matters

Affected versions of fast-xml-parser are vulnerable to Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion'). fast-xml-parser can be denial-of-service'd via uncontrolled XML entity expansion: a crafted XML document with a DOCTYPE that defines a large plain-text entity and references it many times causes OrderedObjParser.replaceEntitiesValue() to repeatedly expand the entity without any limit on output size or replacement work, blocking the Node.js event loop and freezing the application while parsing untrusted XML (mitigate by disabling entity/DOCTYPE processing, e.g., processEntities: false).

References: GHSA, CVE

To resolve this comment:
Check if you are using fxparser on the CLI.

• If you're affected, upgrade this dependency to at least version 5.3.6 at pnpm-lock.yaml.
• If you're not affected, comment /fp we don't use this [condition]

💬 Ignore this finding

To ignore this, reply with:

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

_{You can view more details on this finding in the Semgrep AppSec Platform here.}

[semgrep-code-getsentry]

High severity vulnerability may affect your project—review required:
Line 3818 lists a dependency (fast-xml-parser) with a known High severity vulnerability.

ℹ️ Why this matters

Affected versions of fast-xml-parser are vulnerable to Improper Input Validation / Uncaught Exception. A RangeError in fast-xml-parser's numeric entity handling allows an attacker to crash any application parsing untrusted XML. The parser uses String.fromCodePoint on decimal or hex entities without bounds checking (e.g. � or �), which throws an uncaught exception and terminates the Node.js process, resulting in a denial-of-service.

References: GHSA, CVE

To resolve this comment:
Check if you are using fxparser on the CLI to parse untrusted XML, such as through fxparser malicious.xml.

• If you're affected, upgrade this dependency to at least version 5.3.4 at pnpm-lock.yaml.
• If you're not affected, comment /fp we don't use this [condition]

💬 Ignore this finding

To ignore this, reply with:

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

_{You can view more details on this finding in the Semgrep AppSec Platform here.}

[semgrep-code-getsentry]

Critical severity vulnerability may affect your project—review required:
Line 3818 lists a dependency (fast-xml-parser) with a known Critical severity vulnerability.

ℹ️ Why this matters

Affected versions of fast-xml-parser are vulnerable to Incorrect Regular Expression. fast-xml-parser is vulnerable to an entity-encoding bypass when parsing untrusted XML with DOCTYPE entities enabled (the default processEntities: true): attacker-controlled DOCTYPE entity names are interpolated into RegExp() without escaping . (dot), so a name like l. becomes a wildcard regex that shadows built-in entities such as <, >, &, ", and ', allowing arbitrary replacement text and leading to XSS (or other injection) when the parsed output is later rendered or used in an injection-sensitive context.

References: GHSA, CVE

To resolve this comment:
Check if you are using fxparser on the CLI.

• If you're affected, upgrade this dependency to at least version 5.3.5 at pnpm-lock.yaml.
• If you're not affected, comment /fp we don't use this [condition]

💬 Ignore this finding

To ignore this, reply with:

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

_{You can view more details on this finding in the Semgrep AppSec Platform here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 3cf268f. Configure here.}

[cursor]

Duplicate close uses wrong reason, misses native linking

Medium Severity

The close-duplicate stage instructs the model to use --reason "not planned" when closing duplicate issues. Since gh CLI v2.88.0 (released March 10, 2026), gh issue close supports --reason duplicate and a --duplicate-of <number> flag that creates a native GitHub duplicate link. Using "not planned" causes the issue to display as "Closed as not planned" in GitHub's UI rather than "Closed as duplicate", and misses the native duplicate relationship that --duplicate-of would provide.

 

^{Reviewed by Cursor Bugbot for commit 3cf268f. Configure here.}

[cursor]

Untrusted canonical title embedded in shell command

Medium Severity

The close-duplicate stage embeds the canonical issue's title — which is untrusted user content — directly into a gh issue close --comment "<comment>" shell command argument. The global rules correctly declare issue titles untrusted, but the close-duplicate template contradicts this by inserting <canonical title> into a comment that is then placed inside a double-quoted shell argument. An attacker who controls the canonical issue's title (e.g., containing $(cmd) or backticks) could achieve shell injection when the model constructs this command. Using --body-file style indirection or instructing the model to write the comment to a temp file first would avoid passing untrusted content through shell interpolation.

 

^{Reviewed by Cursor Bugbot for commit 3cf268f. Configure here.}