Hacker News: e1g

New comment by e1g in "DeepInfer: High-performance inference framework for DeepSeek models"

e1g — Tue, 20 Oct 2026 16:34:20 +0000

+1; using Sol 6.1 in Ultrafast is noticeably faster than DS 4.1 Flash in real world tasks where marginal intelligence and token efficiency matters. Yes it costs more, but that’s a function of how valuable is the thing you are iterating on.

New comment by e1g in "Cloudflare K2: serverless event streams"

e1g — Thu, 01 Oct 2026 19:25:25 +0000

I'm doing some testing, and while my writes are <1s, I'm seeing E2E delivery latency of p95=2.5s / p99=7.5s. Is this roughly expected?

New comment by e1g in "A Design Space Exploration of Async/Await"

e1g — Sat, 12 Sep 2026 09:26:19 +0000

A hallmark of good architecture is adaptability to unexpected changes in requirements. Planning ahead helps with 'known unknowns', but it's impractical when building across N years in a dynamic environment - "knowing ahead of time" is just not possible for anything non-trivial. You need strong architectural primitives that don't scale based on developers' omniscience.

For example, say you have a workflow where, when someone signs up, you generate a user label, e.g., `$firstName $lastName`. You decide to move that to a function that might consider their personal title, preferred name, etc. Currently, it's a pure sync operation. Then, you discover people don't fill out that form at all, but some log in with Google, and you can use the name there as a fallback. Under flexible, this change is local: you can put that into your `createUserLabel(userInfo)`, and it can decide to fire off an API call to fill in any missing data, etc. In Promises land, this would taint the entire tree of everything everywhere that called that method, and all of those things must evolve or be refactored. In an Effectful system, this (previously unplanned) change remains isolated to that one function. Multiply that by every decision over multiple years for software looking for PMF, and requiring developers to "know ahead" severely slows down your ability to evolve.

New comment by e1g in "A Design Space Exploration of Async/Await"

e1g — Sat, 12 Sep 2026 08:13:44 +0000

Tactically, this problem is commonly known as “colored functions”[1], and the only option in JS is to have some other runtime coordinate your function execution; in JS, that solution is Effect[2]

[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

[2] https://effect.website/

New comment by e1g in "Auto mode is now the default in Claude Code"

e1g — Tue, 11 Aug 2026 17:41:15 +0000

“safehouse ” hides and protects your filesystem from the agent CLI - it cannot read/write/delete anything outside of the current folder, no matter what Bash/code it tries (short of finding some 0-day within MacOS sandboxing). We added exceptions for dev tooling (so eg NPM works), but generally keep same defaults (eg no Docker access by default as having that socket bypasses all protection)

New comment by e1g in "Auto mode is now the default in Claude Code"

e1g — Mon, 10 Aug 2026 12:06:53 +0000

On a Mac, you can do this via OS-native Seatbelt sandboxing - you define a static text file and it locks down the process so it can't read/write anything it's not supposed to. The syntax is a bit archaic, so I built a Bash wrapper around it to dynamically detect which agent you use and from what dir, and then generate the policy to lock down its process - https://github.com/eugene1g/agent-safehouse

New comment by e1g in "The front end framework for correctness: built on Effect, architected like Elm"

e1g — Fri, 24 Jul 2026 17:59:21 +0000

It took me 3 months to go from “I will never use it” to “I will never not use it”. Plus it’s always fun to watch the creators of Effect get confused about which brackets to where. The syntax is archaic, luckily we don’t write syntax by hand any more.

New comment by e1g in "Ask HN: Secure wrapper for coding agents?"

e1g — Thu, 02 Jul 2026 17:02:03 +0000

Unfortunately, no, MacOS sandboxing does not allow that type of blocking. Only broad categories like "local" vs "remote", but no selective targeting based on domain names or IPs.

New comment by e1g in "Ask HN: Secure wrapper for coding agents?"

e1g — Thu, 02 Jul 2026 11:08:35 +0000

Safehouse author here - glad you found it helpful. It didn't even occur to me to add --offline mode because my mental model is anchored in agents which often require network access. Until we add this, the easiest option is to create a custom policy and then reference it with Safehouse (I usually setup shell aliases/funciton for this)

  ;; in ~/.config/agent-safehouse/no-network.sb
  (deny network*)

  safehouse --append-profile="$HOME/.config/agent-safehouse/no-network.sb" --

New comment by e1g in "How to make SSE token streams resumable, cancellable, and multi-device"

e1g — Fri, 08 May 2026 10:38:18 +0000

In JS land, this problem (streaming, resuming, recovering, multi-client, etc) has been fully solved by https://durablestreams.com - and it can be self-hosted, or managed via Cloudflare DO.

New comment by e1g in "Spain's parliament will act against massive IP blockages by LaLiga"

e1g — Thu, 30 Apr 2026 16:31:45 +0000

We actually had to revert our rollout of CF Workers because enough of our users were in Spain and couldn’t access endpoints at seemingly arbitrary times (due to the matches)

New comment by e1g in "Don't YOLO your file system"

e1g — Sat, 28 Mar 2026 02:57:09 +0000

For jailing local agents on a Mac, I made Agent Safehouse - it works for any agent and has many sane default for developers https://agent-safehouse.dev

New comment by e1g in "Agent Safehouse – macOS-native sandboxing for local agents"

e1g — Tue, 10 Mar 2026 06:57:20 +0000

Yes, you're correct about 'no nested sandboxing'.

This also applies to sandboxing an Electron app: Electron has its own built-in sandboxing via sandbox-exec, so if you're wrapping an Electron app in your own sandboxing, you have to disable that inner sandbox (with Electron's --no-sandbox or ELECTRON_DISABLE_SANDBOX=1). In the repo, I have examples for minimal sandbox-exec rules required to run Claude Code[1] and VSCode[2] (so you can do --dangerously-skip-permission in their destop app and VSCode extension)

[1] https://github.com/eugene1g/agent-safehouse/blob/a7377924efa...

[2] https://github.com/eugene1g/agent-safehouse/blob/a7377924efa...

New comment by e1g in "Agent Safehouse – macOS-native sandboxing for local agents"

e1g — Mon, 09 Mar 2026 08:32:00 +0000

Claude Code and Codex quickly figure out they are inside sandbox-exec environment. Maybe because they know it internally. Other agents often realize they are being blocked, and I haven't seen them go haywire yet.

Big love for Pi - it was the first integration I added to Safehouse. I wanted something that offers strong guarantees across all agents (I test and write them nonstop), has no dependencies (e.g., the Node runtime), and is easy to customize, so I didn't use the Anthropic sandbox-runtime.

New comment by e1g in "Agent Safehouse – macOS-native sandboxing for local agents"

e1g — Mon, 09 Mar 2026 07:35:18 +0000

SBPL is great for filesystem controls and I haven’t hit roadblocks yet. I wish it offered more controls of outbound network requests (ie filtering by domain), but I understand why not.

Yes, Safehouse should work for xcodebuild workloads in the way you described - try to run it, watch for failures, extend the profile, try again. Your agent can do this in a loop by itself - just feed it the repo as there are many integrations that are not enabled by default that will help it.

New comment by e1g in "Agent Safehouse – macOS-native sandboxing for local agents"

e1g — Mon, 09 Mar 2026 07:30:30 +0000

Thanks, Codex helped to put that together in like 20 minutes. Try feeding your agent the idea about an interactive config builder, give it the upstream URL with your condos, and see if it can whip up something for you.

New comment by e1g in "Agent Safehouse – macOS-native sandboxing for local agents"

e1g — Mon, 09 Mar 2026 07:28:29 +0000

That’s a great idea. I think I’ll restructure the entire project to be based around a collection of community managed rules, a UI generator to build a custom text file from those rules, and an LLM skill so people can evolve their policies themselves. The Bash script will remain in the background as one implementation, but shouldn’t be the only way.

New comment by e1g in "Agent Safehouse – macOS-native sandboxing for local agents"

e1g — Mon, 09 Mar 2026 02:29:08 +0000

Let’s make something so popular and useful that they can’t drop it.

New comment by e1g in "Agent Safehouse – macOS-native sandboxing for local agents"

e1g — Mon, 09 Mar 2026 02:08:17 +0000

IYKYK, it’s the new Bootstrap!

The alternative would be “no site”, which is still somehow worse.

New comment by e1g in "Agent Safehouse – macOS-native sandboxing for local agents"

e1g — Mon, 09 Mar 2026 01:56:49 +0000

Yes, for about a decade. But it’s available everywhere, and still works - and protects us - like brand new!