DEV Community

Cover image for Styx: Hacktoberfest Open-Source AI Challenge!
Nic Flemmer
Nic Flemmer

Posted on

Styx: Hacktoberfest Open-Source AI Challenge!

Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass Submission 🌿

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Coding agents were supposed to give us our time back. For me they did the opposite.

A few months ago I had four agents running across five projects. I couldn't leave my desk, because any one of them might be waiting on me or about to do something I'd regret, like deploy to production or run a migration on the live database. One had been waiting for twenty minutes before I noticed, and I didn't even know which one. I wasn't coding; I was babysitting.

So I built Styx, a free, open-source desktop app (Apache-2.0) that runs your coding agents on all your projects at once, and makes it safe to walk away from them.

Every task works on its own. Each one gets its own git branch and worktree, so agents don't step on each other or on you.

Nothing touches the real world without you. When an agent wants to deploy, touch a database or SSH into a server, it has to ask. Your keys stay in your computer's keychain; the agent never holds them. Production needs your fingerprint (Touch ID), Windows Hello or your password, and the access expires on its own.

When you come back, one list tells you what needs you. Whatever is waiting on you sits at the top, marked Your turn. Everything else kept working or waited safely.

So it's for developers who run AI coding agents and want to get up and leave. Go for a run, cook dinner, sit in the sun, and come back without wondering what your agents did while you were gone. It won't take you outside on its own, but it removes the reason you were stuck inside.

Demo

Download (Mac, with Windows and Linux in beta): https://heystyx.com

Docs: https://heystyx.com/docs

!A coding agent asks for production database access; it's approved for one hour and carries on

A Codex task asks for write access to the production Supabase database. I review the request, approve it for an hour, and it carries on. Until then it simply waited.

Code

GitHub logo NicholasFlemmer / styx-app

Styx is where everything converges: every repo you work in, the AI coding agents building in them, and every login they need to ship. Switch between all of it from one window. And like the river it's named after, nothing crosses over without you. Deploying, or touching live data, asks you first.

Styx

Styx

Run Claude Code, Codex, Gemini and Cursor on all your projects at once.
They ask before they touch production.

Download for Mac  ·  Download for Windows  ·  Linux  ·  Docs  ·  Website  ·  Watch the story (1:42)

Contribute: Add an agent  ·  Add a deploy target  ·  Contributing guide

CI License: Apache-2.0 macOS · Windows · Linux


A Codex task asks for write access to the production Supabase database; you review the request and grant it for an hour, and the task carries on

You already use coding agents. The hard part is everything around them: one agent per terminal, each on whatever branch it found, your deploy keys sitting in a .env they can all read, and no idea which one is waiting on you.

Styx is one window for all of it. Every project you work on, every agent working in them, and every login they need to ship. Each task gets its own branch, so agents never trip over each other. And when one wants to deploy, migrate a database or touch anything live, it has to ask you first.

Get

…

How I Built It

Styx is an Electron and React app. It doesn't bring its own model. It drives the agent command-line tools you already have and are signed in to, each in the way that tool talks best:

Codex CLI (open source, Apache-2.0), over its app-server protocol, so you can message it mid-turn;

Gemini CLI (open source, Apache-2.0), over the open Agent Client Protocol (ACP);

Claude Code and Cursor's agent.

The safety layer is the part I'm proudest of, and it's all in the repo:

Agents reach real services through small shims for vercel, gh, aws, gcloud, supabase and ssh, plus an MCP tool. Both go through a local broker, and each connection is bound to one agent session.

A pure policy function decides: allow, ask, or deny. Anything Styx doesn't recognise counts as a write. A command that doesn't say whether it means staging or production is treated as production.

Approvals are scoped and time-limited, and every request, approval, use and revoke goes into a tamper-evident audit log (SQLite, with each row hash-chained to the one before).

I built most of it by running agents on the Styx repo itself, several at a time, each on its own branch, which is how I found most of the problems it now solves. I wrote up how the safety layer works here: https://heystyx.com/blog/keeping-agents-away-from-production

In fairness to the prompt: Styx doesn't run open-weight models or local inference today. The models behind these tools are hosted. Its open-source AI is the harness layer: two open-source agent CLIs, an open protocol (ACP), and Styx itself.

Why Does Open Innovation Matter?

Software that decides when an AI agent can touch your production database should be software you can read. "Trust us" isn't good enough for that job, so the code that hands out access, the policy engine and every provider adapter are public. The docs also list exactly what Styx doesn't protect against, because it's a guardrail, not a sandbox.

Open harnesses mattered just as much. Codex CLI and Gemini CLI being open source, and ACP being an open protocol, is what let one person make four different agents behave the same way: stop, ask, wait. With closed tools I'd have been guessing at their behaviour; with open ones I could read how they work and build to it.

And open source means Styx grows past me. Adding the next agent (Aider, Goose, OpenCode, Amp) or deploy target (Netlify, Fly.io, Railway, Render, Cloudflare) is a good first issue with a step-by-step guide. Someone has already sketched how a Cloudflare target should split preview from production access.

Top comments (0)