Developers lack fine-grained controls for running untrusted scripts
Developers running user-provided scripts or sandboxed automation need to restrict filesystem and network access without blocking legitimate access to local services. The signals describe gaps in runtime and terminal controls, including denied localhost connections that can break health checks. One reported workaround uses file-based health witnesses and `lsof` instead of ordinary localhost HTTP checks.
For developers building script runners and sandboxed automation. Mentioned from Sep 2016 to Aug 2026 on GitHub.
4 different people described this problem in 4 separate discussions.
- Indie fit
- 5.0/10
- Pain
- 7.0/10
- Frequency
- 5.8/10
- Willingness to pay
- 0.0/10
- Momentum
- 4.7/10
- Who pays
- Businesses
- Competition
- High
- Build difficulty
- High
What people said
Quoted word for word. Follow a link to read the whole discussion.
Allows to run BUN as sandbox to safely run users provided scripts
Until then we're working around it with file-based health witnesses (the sandbox allows file reads and lsof -iTCP), which works but shouldn't be necessary for plain localhost HTTP. A port-scoped loopback allowlist would resolve this cleanly
Build brief
See what to build and who will buy it
- 2 product ideas with the smallest useful version and pricing
- 4 places to find your first customers
- 2 more quotes from people who have this problem
- Current workarounds, existing solutions and risks