? Curious Hacker Newsfront | about | examples | prompts | view on HN unofficial mirror
Show HN: Stroq – a local audit of what your coding agent did and why (github.com)
76 points by agybay_07 2026-11-05 | 24 comments | side by side | 0 rewritten | show 1 removed | updated 04:43 UTC
 help



Interesting. How does it know: rule based, small model, or LLM? Anyway, like the mascot

Interesting. How does it know: rule based, small model, or LLM? Anyway, like the mascot

A genuine, on-topic question about how the tool works, posed in good faith.
agybay_07 2026-11-06 04:435/10first_handinformative | parent [–]

Thanks, the owl's name is Hoo) Stroq reads sessions logs and command text directly from the computer. There are no LLM models involved

Thanks, the owl's name is Hoo) Stroq reads sessions logs and command text directly from the computer. There are no LLM models involved

The author directly answers the question: Stroq reads local logs and commands without using LLMs.

Doing it with a high-performance LLM would be best, but I think the token and time cost would be big, and just doing it code-based seems like it could work to some extent. But later, if LLM alignment gets good, it might not even be needed.

Doing it with a high-performance LLM would be best, but I think the token and time cost would be big, and just doing it code-based seems like it could work to some extent. But later, if LLM alignment gets good, it might not even be needed.

A modest but real take on the tradeoff between LLM-based and rule-based auditing.
agybay_07 2026-11-06 03:225/10first_handinsightful | parent [–]

Yes, the rules dont catch everything but since this is an open-source project, anyone can add new rules, and I'll be looking for new approaches. as for the llm, it reads the same text as the agent, so it can be fooled as well)

Yes, the rules dont catch everything but since this is an open-source project, anyone can add new rules, and I'll be looking for new approaches. as for the llm, it reads the same text as the agent, so it can be fooled as well)

The project author acknowledges the rules' limits and notes an LLM reviewer can be fooled by the same text.

Of course, I do think it's really great in terms of cost. And since it's open source, it also has the advantage of being customizable.

Of course, I do think it's really great in terms of cost. And since it's open source, it also has the advantage of being customizable.

Friendly, on-topic remark about cost and customizability; minor but sincere.
philips 2026-11-05 23:337/10first_handinformativeinsightful | prev | next [–]

I have been working on putting agents into full gVisor isolation with a default deny egress proxy that includes secret injections. When an agent tries to connect outbound, by default it suspends the gVisor, holds the proxy connection open, and lets the user choose.

I am adding external judges now. But, there is a hypervisor key you press to deny/allow hosts without switching terminals.

I just can't get behind relying on the harness tool boundry to protect me.

I have been working on putting agents into full gVisor isolation with a default deny egress proxy that includes secret injections. When an agent tries to connect outbound, by default it suspends the gVisor, holds the proxy connection open, and lets the user choose.

I am adding external judges now. But, there is a hypervisor key you press to deny/allow hosts without switching terminals.

I just can't get behind relying on the harness tool boundry to protect me.

First-hand description of a gVisor and default-deny egress design for agents, with a clear view on harness trust boundaries.
hedgehog 2026-11-06 02:055/10questionfirst_hand | parent [–]

Are putting the agent core and the workspace in separate containers? I do a limited version of that to prevent runaway tests etc from stopping jobs but making it a stronger boundary seems like a good idea.

Are putting the agent core and the workspace in separate containers? I do a limited version of that to prevent runaway tests etc from stopping jobs but making it a stronger boundary seems like a good idea.

A genuine technical question that shares a related practice from the commenter's own setup.
philips 2026-11-06 02:484/10first_handinformative | root | parent [–]

Yes. Very alpha. https://hshrun.org

Yes. Very alpha. https://hshrun.org

Direct answer to the question with a link to the author's own project.

Would love to collaborate with you on this since we’re building something analogous internally.

Would love to collaborate with you on this since we’re building something analogous internally.

A sincere collaboration offer that notes a similar internal project; nothing to moderate.
maven29 2026-11-05 19:047/10informativeinsightful | prev | next [–]

You could cover a lot more adversarial scenarios with an ebpf backend. It needs linux, but with all the patches going around, you should be doing all your dev in a VM anyway. https://eunomia.dev/agentsight/

You could cover a lot more adversarial scenarios with an ebpf backend. It needs linux, but with all the patches going around, you should be doing all your dev in a VM anyway. https://eunomia.dev/agentsight/

Substantive technical suggestion with a useful link to an eBPF-based alternative.

[flagged]

From the README, matching is text-level and nothing is sent out. So it seems to judge with rules, not an LLM. Is that right?

From the README, matching is text-level and nothing is sent out. So it seems to judge with rules, not an LLM. Is that right?

Genuine, on-topic question about how the tool works, grounded in the README.

yes

yes

Short, but it is the project author directly confirming how matching works.

I've built project that helps to protect your computer from dangerous commands that your ai agent might execute. Have you noticed how often dont even check what our agents are actually running? Thats why I created Stroq. Try it locally npx @stroq/cli

I've built project that helps to protect your computer from dangerous commands that your ai agent might execute. Have you noticed how often dont even check what our agents are actually running? Thats why I created Stroq. Try it locally npx @stroq/cli

Author's own Show HN introduction explaining the project's purpose and how to try it; no moderation issue.

> helps to protect your computer from dangerous commands that your ai agent might execute

How does "a local audit of what your coding agent did and why" help prevent dangerous commands? Sounds like your solution comes too late, innit? Sure, I can see that at 16:48 the agent ran "rm -rf --no-preserve-root" but if it already executed it on my personal computer, isn't it too late then?

Personally, I think this solves the wrong problem. If you're one stray "rm" away from letting the agent delete stuff on your personal computer, you're running the agent harness the wrong way. At least give it its own user, ideally limit what paths/network it can use, but don't rely on "auditing" to prevent dangerous commands, it'll bite you in the future.

> helps to protect your computer from dangerous commands that your ai agent might execute

How does "a local audit of what your coding agent did and why" help prevent dangerous commands? Sounds like your solution comes too late, innit? Sure, I can see that at 16:48 the agent ran "rm -rf --no-preserve-root" but if it already executed it on my personal computer, isn't it too late then?

Personally, I think this solves the wrong problem. If you're one stray "rm" away from letting the agent delete stuff on your personal computer, you're running the agent harness the wrong way. At least give it its own user, ideally limit what paths/network it can use, but don't rely on "auditing" to prevent dangerous commands, it'll bite you in the future.

Firm, substantive criticism that an after-the-fact audit can't prevent damage, with concrete sandboxing advice.

You are correct, but it's generally very hard to come up with good access control policies up front. Also, as you grant more access the system tends to become over-permissioned over time, and often you don't really find out until so wrong that it hurts. The ability to audit is necessary to maintain good policies. It allows you to discover gaps in your policy even when things didn't break terribly.

You are correct, but it's generally very hard to come up with good access control policies up front. Also, as you grant more access the system tends to become over-permissioned over time, and often you don't really find out until so wrong that it hurts. The ability to audit is necessary to maintain good policies. It allows you to discover gaps in your policy even when things didn't break terribly.

Civil, substantive reply explaining why auditing complements access control by exposing policy gaps and over-permissioning.
agybay_07 2026-11-05 18:236/10first_handinformative | root | parent | prev | next [–]

You’re right the command from my comment only generates a report and doesn’t actually prevent anything. stroq init sets up hooks that prompt for confirmation before a dangerous command is executed—but that’s a filter, not a sandbox

You’re right the command from my comment only generates a report and doesn’t actually prevent anything. stroq init sets up hooks that prompt for confirmation before a dangerous command is executed—but that’s a filter, not a sandbox

The project author concedes the criticism and clearly explains that the hooks are a confirmation filter rather than a sandbox.
brkomir 2026-11-05 20:169/10first_handinformativeinsightfulquestion | root | parent [–]

I have received two pre-interview repos from recruiters on LinkedIn (NK hackers targeting crypto people), and both would be hard cases for this. Almost all offers there in DMs are now fake recruiters, and it's not trivial to figure out if the account is fake.

One had an eval() hidden inside a controller function named getCookie(), running whatever a remote server sent back. npm start, npm build and npm test all triggered it. Cursor didn't catch it when I asked "is this repo safe to run?" and then told it to check all dependencies.

Other one came as a bunch of Solidity files in a zip file with an issue to resolve as the interview task, nothing suspicious at first sight. However, that zip carried the whole .git folder, hooks included, which a git clone never copies, and the folder is hidden by default in Finder. Of course, there was a hook that fires on any commit or push, again eval() on some remote address.

In both cases the agent only runs npm test or git commit. Would Stroq see anything in these situations?

I have received two pre-interview repos from recruiters on LinkedIn (NK hackers targeting crypto people), and both would be hard cases for this. Almost all offers there in DMs are now fake recruiters, and it's not trivial to figure out if the account is fake.

One had an eval() hidden inside a controller function named getCookie(), running whatever a remote server sent back. npm start, npm build and npm test all triggered it. Cursor didn't catch it when I asked "is this repo safe to run?" and then told it to check all dependencies.

Other one came as a bunch of Solidity files in a zip file with an issue to resolve as the interview task, nothing suspicious at first sight. However, that zip carried the whole .git folder, hooks included, which a git clone never copies, and the folder is hidden by default in Finder. Of course, there was a hook that fires on any commit or push, again eval() on some remote address.

In both cases the agent only runs npm test or git commit. Would Stroq see anything in these situations?

First-hand account of two real malicious repos, with concrete techniques and a genuine question about whether the tool would catch them.
agybay_07 2026-11-05 20:496/10first_handinformative | root | parent [–]

to be honest, in the first scenario, the hook will only detect 'nom test' command itself. in the second scenario 'stroq inspect' will identify the hook before the folder is opened and issue a warning. thanks for these examples :) I'll use them to improve product

to be honest, in the first scenario, the hook will only detect 'nom test' command itself. in the second scenario 'stroq inspect' will identify the hook before the folder is opened and issue a warning. thanks for these examples :) I'll use them to improve product

The tool's author candidly explains what it would and wouldn't catch in each of the reported attack scenarios.

[flagged]

feature suggestion:

background daemon that continuously scans and alerts in a menubar app when a positive match is found

clicking the menubar app shows the offending entry, clicking the entry lets you redact, delete, repair, mark as false positive, etc.

feature suggestion:

background daemon that continuously scans and alerts in a menubar app when a positive match is found

clicking the menubar app shows the offending entry, clicking the entry lets you redact, delete, repair, mark as false positive, etc.

A concrete, constructive feature suggestion with a specific workflow for the tool.

Thanks) good idea

Thanks) good idea

A brief, friendly acknowledgement from the project's author to a feature suggestion; harmless and in good faith.

I'm wondering if that could be part of a prompt injection warn system in the future. Did I get it right, that it does not need an LLM to evaluate sessions?

I'm wondering if that could be part of a prompt injection warn system in the future. Did I get it right, that it does not need an LLM to evaluate sessions?

Genuine question about the tool's design and a possible prompt injection use case.
agybay_07 2026-11-06 02:514/10first_handinformative | parent [–]

Yes, that’s correct. the rules already flag this kind of text

Yes, that’s correct. the rules already flag this kind of text

The project author confirms no LLM is needed and that rules already flag such text.
MakazhanAlpamys 2026-11-05 19:52 | removed0/10low_effort | prev | next [–]

homie lets keep building

homie lets keep building

Pure encouragement with no substance about the project.
q17 2026-11-05 22:041/10jokelow_effortkept_for_replies | prev | next [–]

cool project! ...so is it pronounced, like, stroke? lol

cool project! ...so is it pronounced, like, stroke? lol

A light, friendly joke about the name's pronunciation; it's thin but not hostile, and the reply needs it for context.

oh no, I hadn't made that connection until now lol

oh no, I hadn't made that connection until now lol

A light, good-humored reply from the author to a question about the name.

[flagged]



About | Details | Examples | Prompts | This page on Hacker News | HN Guidelines | Data: HN API

Curious Hacker News is an unofficial, experimental mirror and is not affiliated with, endorsed by, or operated by Hacker News or Y Combinator. Original comments are by their authors on news.ycombinator.com; rewritten text is AI-generated and was not written by the commenter.