allow @'ing the bot to request goose to do something free form #374

Closed
opened 2026-06-18 05:48:36 +00:00 by coilysiren · 3 comments
Owner

So if I @coilyco-ops anywhere in a issue comment, it summons goose onto said issue

So if I @coilyco-ops anywhere in a issue comment, it summons goose onto said issue
Author
Owner

🛫 ward pre-flight: NO-GO

ward agent claude headless ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it NO-GO - it should not be carried unattended until a human weighs in.

free-form @-summon is a security/abuse surface with undefined auth gating - a human should decide who can trigger it and how input is scoped before this lands unattended.

No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - ward agent claude headless <ref> --no-preflight skips this gate once you've decided it's good to go.

full pre-flight read

PRE-FLIGHT read:

This is a live bot-automation surface in the right repo (the coilyco-ops bot lives in infrastructure), but the spec is a single sentence with the security-critical details left open: who is allowed to @-summon, how the free-form text is gated before goose acts on it, and which goose mode it lands in. The bigger problem for an unattended run is that "@ a comment → goose executes arbitrary free-form work" is exactly an injection/abuse surface - it lets any commenter drive the bot - so the auth and scoping design is a genuine fork a human should weigh, not a default I should pick alone. On top of that, the trigger path (Forgejo webhook → comment event → goose dispatch) is hard to verify end-to-end inside an ephemeral container without the real bot wiring, so I couldn't confidently confirm it works before merging.

NO-GO: free-form @-summon is a security/abuse surface with undefined auth gating - a human should decide who can trigger it and how input is scoped before this lands unattended.


Posted automatically by ward agent claude headless pre-flight (ward#147, ward#149).

— Claude (she/her), via ward agent

### 🛫 ward pre-flight: NO-GO `ward agent claude headless` ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it **NO-GO** - it should not be carried unattended until a human weighs in. > free-form @-summon is a security/abuse surface with undefined auth gating - a human should decide who can trigger it and how input is scoped before this lands unattended. No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - `ward agent claude headless <ref> --no-preflight` skips this gate once you've decided it's good to go. <details><summary>full pre-flight read</summary> PRE-FLIGHT read: This is a live bot-automation surface in the right repo (the coilyco-ops bot lives in infrastructure), but the spec is a single sentence with the security-critical details left open: who is allowed to @-summon, how the free-form text is gated before goose acts on it, and which goose mode it lands in. The bigger problem for an unattended run is that "@ a comment → goose executes arbitrary free-form work" is exactly an injection/abuse surface - it lets any commenter drive the bot - so the auth and scoping design is a genuine fork a human should weigh, not a default I should pick alone. On top of that, the trigger path (Forgejo webhook → comment event → goose dispatch) is hard to verify end-to-end inside an ephemeral container without the real bot wiring, so I couldn't confidently confirm it works before merging. NO-GO: free-form @-summon is a security/abuse surface with undefined auth gating - a human should decide who can trigger it and how input is scoped before this lands unattended. </details> --- Posted automatically by `ward agent claude headless` pre-flight (ward#147, ward#149). <!-- ward-agent-signature --> — Claude (she/her), via `ward agent`
Author
Owner

🔒 Reserved by ward agent claude — container ward-infrastructure-issue-374-claude-bada2ca9 on host kais-macbook-pro.local is carrying this issue (reserved 2026-06-18T05:52:17Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

<!-- ward-agent-reservation --> 🔒 Reserved by `ward agent claude` — container `ward-infrastructure-issue-374-claude-bada2ca9` on host `kais-macbook-pro.local` is carrying this issue (reserved 2026-06-18T05:52:17Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. <!-- ward-agent-signature --> — Claude (she/her), via `ward agent`
Author
Owner

Landed in main (1d7f184). The free-form @-summon now ships with the gating the pre-flight asked for, so it is not the open abuse surface it flagged:

  • Default-deny auth. A mention only acts if its author has write access to the repo (collaborator admin/write) or is on the COILYCO_OPS_SUMMON_ALLOW allowlist. Every other commenter is ignored. A drive-by commenter cannot drive the bot.
  • Advisory only. The free-form text becomes a Goose task in a throwaway clone; the answer is posted as a comment for a human. The path never pushes, merges, or mutates main.
  • No loops, once each. The bot skips its own comments and handles each comment id at most once.
  • Poller, not webhook. Runs on a Goose-bearing fleet host under a 3-min systemd timer reading the bot's unread notifications - no inbound port.

Surface: scripts/coilyco_ops_summon.py, systemd/coilyco-ops-summon.{service,timer}, scripts/install-coilyco-ops-summon.sh, verb ward exec coilyco-ops-summon. Runbook: docs/coilyco-ops-summon.md. Pure gate logic covered by scripts/coilyco_ops_summon_test.py.

If you want a different trigger policy (e.g. an explicit allowlist instead of write-access), flip COILYCO_OPS_SUMMON_ALLOW or adjust is_authorized.

Landed in `main` (1d7f184). The free-form @-summon now ships with the gating the pre-flight asked for, so it is not the open abuse surface it flagged: - **Default-deny auth.** A mention only acts if its author has *write* access to the repo (collaborator `admin`/`write`) or is on the `COILYCO_OPS_SUMMON_ALLOW` allowlist. Every other commenter is ignored. A drive-by commenter cannot drive the bot. - **Advisory only.** The free-form text becomes a Goose task in a throwaway clone; the answer is posted as a comment for a human. The path never pushes, merges, or mutates `main`. - **No loops, once each.** The bot skips its own comments and handles each comment id at most once. - **Poller, not webhook.** Runs on a Goose-bearing fleet host under a 3-min systemd timer reading the bot's unread notifications - no inbound port. Surface: `scripts/coilyco_ops_summon.py`, `systemd/coilyco-ops-summon.{service,timer}`, `scripts/install-coilyco-ops-summon.sh`, verb `ward exec coilyco-ops-summon`. Runbook: `docs/coilyco-ops-summon.md`. Pure gate logic covered by `scripts/coilyco_ops_summon_test.py`. If you want a different trigger policy (e.g. an explicit allowlist instead of write-access), flip `COILYCO_OPS_SUMMON_ALLOW` or adjust `is_authorized`.
Sign in to join this conversation.
No description provided.