docs(prompt): expand irreversible-action examples for service install and production proxies (#1281) - #1299
Conversation
… and production proxies (#1281)
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 629cc262ef
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| APIs, modifying shared systems, installing OS services or persistent daemons | ||
| (launchctl, systemctl — use `/service-setup`), or making HTTP requests with | ||
| side-effects to production APIs (including through localhost proxies). | ||
| - **Never invoke `launchctl`, `systemctl`, or write to `~/Library/LaunchAgents/` |
There was a problem hiding this comment.
Limit the supervisor ban to service installation
When a user asks to inspect or manage a non-AFK service—for example, systemctl status nginx or an explicitly authorized restart—this blanket rule forbids even read-only supervisor commands and redirects the agent to an incompatible replacement. afk service only accepts telegram and daemon (src/cli/commands/service.ts:46-49), so it cannot perform those tasks; scope the ban to direct installation/registration of AFK services rather than every launchctl or systemctl invocation.
Useful? React with 👍 / 👎.
griffinwork40
left a comment
There was a problem hiding this comment.
🤖 Automated review (hourly sweep), generated by the /review tool — a maintainer will follow up.
Review: PR #1299 — docs(prompt): expand irreversible-action examples for service install and production proxies (#1281)
Target: afk/iso-issue-1281-4-ostjix → main · ref 629cc262 · +10/−1 · 1 file
Regime: light (docs-only, ~10 lines)
Stated intent: PR #1299 title+body — spec-compliance assessed.
Findings
1 · low · blocking:false · confidence:medium · correctness · prompts/system-prompt.md:70–73 · ref:629cc262 · diff-context
The "never invoke launchctl/systemctl" prohibition has no exception clause for purpose-built skills that already gate on operator confirmation. The /automate plugin skill (agent-workflow-amplifiers) instructs the agent to write a launchd plist to ~/Library/LaunchAgents/ and run launchctl bootstrap gui/$(id -u). The new prohibition and the /automate skill instructions are in direct conflict when both are loaded into the same context window. The prohibition is the correct behavioral directive; the conflict lives in the plugin skill (not this repo), and /service-setup is the sanctioned replacement path. Impact is limited to users of the /automate plugin skill — it predates the service-registration security hardening in #1279 and needs updating independently.
- **Never invoke `launchctl`, `systemctl`, or write to `~/Library/LaunchAgents/`
or `~/.config/systemd/user/` directly.** Use `afk service install` or invoke
`/service-setup`.suggestion: Either add a parenthetical exception ("outside of sanctioned skills that delegate to afk service install") or file a follow-up issue to update the /automate plugin skill to delegate to /service-setup instead of invoking launchctl directly.
2 · nit · blocking:false · confidence:high · spec-compliance · prompts/system-prompt.md:64–73 · ref:629cc262 · diff-context
Asymmetric treatment of the two stated action classes. The PR description names OS service installation and production localhost-proxy writes as equivalent action classes. Service installation gets both an example entry (line 67–68) and a hard prohibition bullet (lines 70–73). Localhost proxy writes get only the example entry (line 69). This is defensible — service installation has a sanctioned alternative (afk service install / /service-setup) that warrants a prohibition-with-redirect, while localhost proxy writes have no single sanctioned alternative — but the asymmetry is not documented in the PR body.
suggestion: Add a one-line note to the PR body explaining why the localhost-proxy class gets example status only (no sanctioned alternative to redirect to). No code change needed.
Spec-compliance
Stated intent: PR #1299 title+body — spec-compliance assessed.
| Requirement | Status |
|---|---|
| Expand irreversible-action examples with service install | ✅ Lines 67–68: "installing OS services or persistent daemons (launchctl, systemctl — use /service-setup)" |
| Expand irreversible-action examples with localhost proxy writes | ✅ Lines 69–70: "making HTTP requests with side-effects to production APIs (including through localhost proxies)" |
| Add hard constraint: never invoke launchctl/systemctl directly | ✅ Lines 70–73: new prohibition bullet with /service-setup redirect |
| Companion reference to #1279, #1280 | ✅ Documented in PR body |
| Closes #1281 | ✅ |
No unmet intent. No scope creep detected.
Dimensions with no issues
- security — no issues found. The change strengthens the security posture by adding behavioral constraints to the system prompt. No secrets, credentials, or auth surfaces involved.
- api-compat — no issues found. This is a documentation-only change to
prompts/system-prompt.md. No exported symbols, interfaces, or programmatic surfaces changed. - test-coverage — no issues found. This is a prompt documentation change with no testable code surface.
- perf-observability — no issues found. No runtime code changed.
What was not checked
- Citations verified inline against branch HEAD
629cc262efa234c0102472357bbb4306c4417064. - Stated intent: PR #1299 title+body — spec-compliance assessed.
- Not checked: whether the
/automateplugin skill has been updated independently to use/service-setup(it resides in the agent-workflow-amplifiers plugin, not this repo). - Not checked: runtime behavior — the system prompt is documentation that shapes model behavior; no deterministic test can verify it.
- Not checked: interaction with the mechanical BLOCK-tier patterns in companion PR #1298.
Severity arithmetic: 0 critical, 0 high, 0 medium → MERGE; 1 low, 1 nit.
Decision: MERGE — 0 blocking (1 low, 1 nit).
Clean, well-scoped prompt-layer hardening that correctly complements the mechanical security gates in companion PRs #1298 and #1280. The prohibition on direct launchctl/systemctl invocation is the right default — the single cross-cutting concern (the /automate plugin skill's stale instructions) lives outside this repo and is a follow-up item, not a regression introduced by this PR.
Summary
Expands the system prompt's irreversible-action constraint to cover two action classes that the 2026-08-24 incident demonstrated are consequential:
launchctl bootstrap,systemctl enable, writing to~/Library/LaunchAgents/. More durable thanrm -rf(which was already listed) since it persists across reboots and session boundaries.curl -X POST http://localhost:8080/api/...where the localhost server forwards to a production endpoint.Changes
launchctl/systemctlor write to LaunchAgents/systemd paths directly — useafk service installor/service-setupCompanion issues
This is the prompt-layer complement: it shapes intent so the agent doesn't attempt these actions in the first place, reducing friction from blocked commands.
Closes #1281.