Maker, meme-r, and unabashed geek, Joe has been writing about technology since starting his career in 2018 at KnowTechie. He's covered everything from Apple to apps and crowdfunding and loves getting to the bottom of complicated topics. In that time, he's also written for SlashGear and numerous corporate clients before finding his home at XDA in the spring of 2023.
He was the kid who took apart every toy to see how it worked, even if it didn't exactly go back together afterward. That's given him a solid background for explaining how complex systems work together, and he promises he's gotten better at the putting things back together stage since then.
I've never been the best coder, whether in college with Assembly or C++, or in any other language I've tried to pick up since. That's changing now that I can use agentic coding tools like Claude Code to explain things as I go, and I've wired them into local models to cut down on token costs. But I still have to set things up on every new machine, and that gets tiresome.
I already run most of my home lab on Proxmox, so I wanted to see if I could set up a centralized agentic coding system I can reach via a browser, without the extra setup time. While looking, I found Jean, which I could set up in an LXC, connect to my local LLMs via OpenCode, and then park it behind Caddy to use my own domain for HTTPS. I swear it's not as complicated as it sounds, and it gives you an agentic workflow that never leaves your home. The hard part is picking the right local models, and learning how to prompt them so they don't go off the rails or claim victory when they haven't actually done any work.
What is Jean, and why would you use it?
It's a workspace that runs agentic coding tasks in parallel, each on its own git worktree
Jean is an open-source (Apache 2.0) workspace from coolLabs, the people behind Coolify. It doesn't run a model itself; instead, it drives agent CLIs, like Claude Code, Codex, OpenCode, Cursor, Pi, Grok, Kimi Code, and Antigravity CLI. Every task gets its own worktree and branch, so your agents don't accidentally write to the main branch, and a headless server daemon serves the full UI in your browser, with an access token keeping it secure.
That means you can start tasks on your laptop, then close it and let the server run them without your attention. Your server keeps those long agent runs going, and you just log into the UI every so often to check on progress or approve any stalled runs. There's a "Magic Menu" with pre-configured prompts for things like commit, review, PR, conflict resolution, and more; you can edit these in the settings, or add your own.
It solves one of my main issues with agentic coding: keeping track of what all of your agents are doing. Plus, it means proper Git versioning of any code, all on the same machine, not spread across whichever devices I've been working from.
Pointing it at a local server makes the whole stack yours and private
While you can use Jean with a variety of cloud subscriptions, part of the appeal of running anything on my Proxmox server is keeping it off the general internet. I wired my dashboard into Lemonade by configuring a locally installed OpenCode CLI as the middleware. Jean can also be installed on a single Windows device, or macOS or Linux (although those latter two aren't as well tested). It works well on an LXC so far for me, although I had one hiccup: an upgraded version of OpenCode broke something, so I had to roll back.
Setting up Jean is easy
Unless you opted to put it on Proxmox, as I did
I expected Jean to be complicated to set up, because that's been my experience with every agentic tool in the last year. It turned out to be the easiest part: one quick Debian 13 unprivileged LXC on Proxmox with four cores, 8GB of RAM, and 32GB of storage later, I had Node LTS, a non-root Jean user, OpenCode, and connections to GitHub (as the non-root user), and Lemonade set up as the OpenCode provider.
The default setup for Jean would have let agents run as root, which I don't want on any device with actual data. Setting it up with --user jean gave me a non-root user and a semblance of safety. Then I threw a block into Caddy for the Jean LXC, which gave me both a local domain and HTTPS, and I was able to start using Jean.
The only gotchas were in the surrounding tooling
I said the Jean install was simple, and I mean that. But like every agentic tool, it's never as simple as installing one thing. The Debian LXC needed the locale set before Perl would stop throwing errors, GitHub login needed to run as jean (not as root), and I had to fix where the Cloudflare API token was stored, so Caddy worked properly with the new container.
None of these are deal-breakers, or really Jean issues. It's par for the course when you're setting up any Linux project with multiple dependencies, and I'm only mentioning them because they came up; you'll almost certainly hit the same things.
Local models took some of the shine off the Jean polish
OpenCode needed a login Jean could see, but then it broke itself
Now, some issues don't show up immediately while installing the program; they only pop up after extended use. It just so happened that Jean and OpenCode both got new updates while I was testing, and I updated both without thinking twice. I should have paused, because something in the latest version of OpenCode (2.0.32) stopped letting me log in correctly, so I couldn't reach my local models. Rolling back to OpenCode 1.19.3 fixed it, and I pinned the version so it can't upgrade without me knowing.
Qwen3 Coder confidently rewrote the worktree path and made its own repo
Jean's worktree path doubles up one of the directories to /home/jean/jean/jean-smoke/hello-script which turned out to be a problem with Qwen3-Coder-Next, which "corrected" things by removing one "jean" from the directory tree, and wrote the code it was told to in the wrong directory. This wouldn't have been a huge problem, but it also ran git init and set up a new global identity to use with git, then committed the file into a repo that I hadn't asked it to create, let alone use.
I'm not sure what in the model made this happen, but explicitly giving the directory tree in the prompt fixed it on subsequent runs. Any agentic workflow could run into this error, whether it's a frontier model or not, and I wouldn't have caught it so quickly if I hadn't been paying attention.
gpt-oss-120b called the right API (but the wrong tools) and claimed it was done without doing the work
Then it was another model's time to shine, and it was more of a candle from the other side of the room. I switched to a new worktree, set the model to gpt-oss-120b, and gave it the same prompt. The first time, it wrote a plan, then stopped. No tool calls, no files. It also claimed that it created the file, chmod'd it, and committed hello.sh, while doing none of that. I remember being called out at school for doing the work in my head, too, but this tool is supposed to do the work.
On another run, it picked the agent-browser MCP that Jean installed and added the worktree path as an allowed domain. Turning the MCP server off stopped it from taking that route, but it kept asking to leave the worktree so it could use the folder it wanted.
Supervised mode stopped it from going off the rails
That was either Auto or unsupervised mode, so I did a few runs with Supervised set to make the agent ask for permission before doing anything. I also tweaked the prompt to mention the explicit worktree path and to use only that folder. The combination worked, and Qwen3-Coder-Next wrote the code as asked in three steps, then committed it to git.
Jean is ready for your home lab, but treat your local LLMs as interns
Setting up Jean was easy, and now I can reach it from any screen in my house. Learning how to best leverage it for getting coding done is trickier, partly from the weird ways local LLMs can get stuck. I'm pretty sure I would have had fewer issues with one of the cloud subscription options, but I wanted to keep everything local.
Jean
Jean provides everything you need to set up a development environment for agentic workflows (except the agents).