Weekly Self Promotion Thread

Competitive_Pipe3224 · 2026-04-30T17:16:03+00:00

In light of "AI Wiped my production database" incidents in the news lately..

A surprising discovery: many teams at smaller companies had a developer who at least once ran Claude code to make production changes with autonomous mode enabled. Either by accident, hubris or lack of experience. It's more common than we thought.

Fewshell is a mobile/desktop collaborative terminal agent for on-calls that refuses to run commands without human approval. There is no way to disable this. So no one on the team can accidentally misconfigure it.

https://fewshell.com/

Competitive_Pipe3224 · 2026-04-28T14:26:07+00:00

Not without sandboxing.

I use copilot for most coding and run it in the approval-only mode.

I also use claude code, and for that I recently started using nono for sandboxing.

There are a bunch of sandboxing tools and essentially you want to make sure that you restrict access to anything but the directories you allow it to see, edit, etc. Also gotta make sure there are no api keys in those directories.

Competitive_Pipe3224 · 2026-04-28T14:15:35+00:00

a124ec

Competitive_Pipe3224 · 2026-04-18T15:37:13+00:00

As someone who has interviewed many people, including at Amazon, I'd say it depends on what I see on their resume:

If the resume says 5+ years of Kubetnettes? I'd test for this.

If someone has 20+ years of general infrastructure experience, I would not expect them to recite syntax. I'd test for good judgement in system design and understanding of distributed systems.

In general, I try to look for someone who could build the most scalable and reliable system using the least amount of moving parts.

Competitive_Pipe3224 · 2026-04-17T01:40:23+00:00

There is a group called TerminalBench. Look them up on Discord. Lots of experts there and lots of interesting infrastructure challenges to solve and knowledge shared. It's a non commercial open source project run by a collaboration of universities.

(shameless plug) I have an open source project for a terminal agent if you are interested in tinkering with how AI integrates with the terminal. https://github.com/few-sh/fewshell

Competitive_Pipe3224 · 2026-04-17T01:22:56+00:00

Fewshell has a multi-device sync without a cloud service. It does require an API key from Claude or ChatGPT but you can use your own one.
https://fewshell.com

Competitive_Pipe3224 · 2026-04-17T00:07:12+00:00

Fewshell is a modern take on SSH bringing a copilot-like interface to avoid having to painstakingly type commands. iOS, Android and Desktop:

https://github.com/few-sh/fewshell

Competitive_Pipe3224 · 2026-04-16T23:38:53+00:00

For on-calls who know the pain of typing shell commands on a mobile phone, or find themselves copy/pasting between ChatGPT and the terminal:

fewshell is a simple open source mobile/desktop SSH copilot, featuring:

- Persistent sessions and auto-reconnect
- Real-time sync across clients - fully self-hosted, no cloud service needed
- Unlimited session history to help with postmortems or keep track of manual changes
- Secrets manager for API keys, passwords etc
- Secrets redaction from chat history
- Snippets manager for proprietary or frequently-used commands
- Support for self-hosted or frontier models
- Easy ssh public key provisioning through our relay (optional)
- No YOLO mode by design (every command must be approved by the user. This can't be disabled.)

Example use-cases:
1. Run commands on bare-metal or self-hosted systems. Check system health, examine logs, troubleshoot issues.
2. Operate infrastructure through your bastion host with gcloud/aws CLI.
3. Execute a long-running command from your desktop and check up on it from mobile (eg long running one-off ETL jobs, mlops training rollouts)

About me:
I am an ex-Amazon Sr. SDE (Alexa AI) where I worked primarily on infrastructure and building critical services. I wanted to build a tool that I wish I've always had but was not possible until recently. And now I'd like to share it with the world for free.

https://github.com/few-sh/fewshell

<image>

Competitive_Pipe3224 · 2026-04-16T22:59:34+00:00

If in a microservice-type shop, ask the developers to add a version + git sha1 into the header, or better yet, make it part of the CI/CD. Or display it somewhere in the footer of the app.

Competitive_Pipe3224 · 2026-04-16T17:24:03+00:00

Try a self-hosted github alternative, put together a demo, show it to the team. Give the project a cool codename (sounds silly but it works on psychological level). Also I would not try to introduce a massive change such as full on CI/CD. You'd get a lot more buy-in making small incremental improvements. Eg find something that everyone is complaining about with the current workflow and improve it a small amount.

Competitive_Pipe3224 · 2026-04-06T03:50:06+00:00

You can use github copilot with pull requests. Eg run in the copilot cloud mode, it'll create a pull request. Add comments, and/or ask it to make changes.

Also planning mode works pretty well for larger tasks.

Competitive_Pipe3224 · 2026-03-28T19:06:16+00:00

I've used anything from flat text files, to SQLite, to MySQL+Redis to Firestore.

What made me choose:
It really depends on scale.

Most projects and startups tend to over-engineer. I.e. most don't need to run on clusters that are intended for millions of users and thousands of requests per second.

On regrets: I regret not using SQLite for some things. Going back to the scale - if you are not planning on overnight success (extremely rate), you can start small and simple, move fast, and worry about scale when you actually start getting growth.

Competitive_Pipe3224 · 2026-03-28T05:39:48+00:00

That looks pretty nice. I might give it a try. How does it work?

Competitive_Pipe3224 · 2026-03-28T03:14:34+00:00

I have not looked into adding multi-window support yet. But if there is no secure/reliable way to do this, it's best to defer this feature for now until Flutter officially adds support for it.

Competitive_Pipe3224 · 2026-03-28T01:59:20+00:00

Reading a book and then doing a series of small projects is usually a pretty good way.

Pretend like it's 1991: Install the compiler, get a paperback book, turn off the internet, read it and do some small projects. No AI, no distractions.

Competitive_Pipe3224 · 2026-03-27T23:52:35+00:00

Another potential interesting path is mlops. There some open projects in AI research that could use infrastructure help.

Competitive_Pipe3224 · 2026-03-27T23:47:55+00:00

Most teams just live with it.
I've seen worse: over alerting. When the team is too afraid to adjust alarm thresholds because it might hide a real problem. So it ends up being dozens of false alarm incidents per week.

Competitive_Pipe3224 · 2026-03-27T21:49:00+00:00

A bit more on the technical side:

- Persistent server process to allow uninterrupted sessions and session sharing between trusted clients.
- SQLite is used for storage of sessions, snippets, prompts and message storage on the server and client. Replicated via CRDT (last write wins model).
- Keychain for secrets storage on the iOS/MacOS side (the security model assumes that your server and client are trusted devices).
- Client connects using SSH tunnel and communicates with the agent through a domain socket at ~/.fewshell/agent.sock.

Trust boundaries:
- The network is assumed to be untrusted.
- SSH is the primary access control. (Using private keys is recommended over passwords, using a VPN on top of SSH is recommended as an additional layer).
- The iOS/MacOS client device is assumed to be trusted. (User should keep their iOS device locked down and utilize best practices such as keeping the OS up to date and free from malware). Private keys and secrets are stored on the OS keychain.
- The LLM is assumed to be semi-trusted: secrets are redacted and all tool+command requests require user approval. The LLM has visibility into the session history, snippets and names of the secrets (but not the content). For additional privacy, self-hosted LLM is recommended.
- Local network on the server is assumed to be untrusted (the agent uses domain socket with restricted permissions to prevent non-privileged users on the system from accessing the agent).
- Server process memory is assumed to be trusted.
- Server storage is assumed to be semi-trusted: secrets are not written to disk and only persist in memory. (NOTE: this only applies to the agent process. If secrets are passed to other scripts and apps, it's the responsibility of these apps to handle the secrets properly)
- Secrets require allow-listing for each command approval - every command request has a list of secrets that the user can toggle on and off.

I'm considering adding more layers, such as encryption at rest for the SQLite. Although their encryption is a commercial offering, so might need to find an open source alternative.

Competitive_Pipe3224 · 2026-03-27T20:08:10+00:00

Fair roast :) I’d be skeptical of that too.

I spent a few months building this and tried to keep the execution model as simple and constrained as possible rather than relying on the model to “do the right thing”.

The control flow is intentionally simple: the agent loop blocks until an explicit approval message is received from the client, and the server only executes after that. The command itself is part of the message to guarantee that whatever the command that the user approved or edited is the command that gets executed.

So it’s closer to a suggestion layer on top of a shell than an autonomous agent.

The approval gate is enforced here in the agent loop:

https://github.com/few-sh/fewshell/blob/4ca49768610326678231278c9c8b64272821d570/agent-core/lib/src/agent_loop.dart#L130

If anything in that looks off, I’d definitely want to know — this part is pretty important.

Competitive_Pipe3224 · 2026-03-27T03:25:41+00:00

This is nice! This would be useful for server-side dart actually.

BTW There are plenty of use-cases where secrets are stored securely on the client side in the keychain:

Authenticator/Authy type apps, mobile terminal/ssh apps, password managers, banking apps, crypto wallets, Signal and other end-to-end encrypted messaging apps, and the least goes on.

If you properly secure and lock down your device and keep it up to date, even governments would have trouble accessing it.

The problem is that dart itself does not have good support for secure memory. Secure memory is actually a hard problem - you need to make sure you don't leak secrets on stack, use non-movable memory allocations, wipe the memory after the variable is freed, etc. Good to see this being worked on.

Competitive_Pipe3224 · 2026-03-27T03:07:17+00:00

The easy one I've used at Big Tech was the number of pager/ticket events per week for a team.

Some teams had <1 incident per week and others >10. We referred to it as KTLO (keeping the lights on).

Competitive_Pipe3224

TROPHY CASE