[HN Gopher] Show HN: Tmux-IDE, OSS agent-first terminal IDE
       ___________________________________________________________________
        
       Show HN: Tmux-IDE, OSS agent-first terminal IDE
        
       Hey HN,  Small OSS project that i created for myself and want to
       share with the community. It's a declarative, scriptable, terminal-
       based IDE focussed on agentic engineering.  That's a lot of jargon,
       but essentially its a multi-agent IDE that you start in your
       terminal.  Why is that relevant? Thanks to tmux and SSH, it means
       that you have a really simple and efficient way to create your own
       always-on coding setup.  Boot into your IDE through ssh, give a
       prompt to claude and close off your machine. In tmux-ide claude
       will keep working.  The tool is intentionally really lightweight,
       because I think the power should come from the harnesses that you
       are working with.  I'm hoping to share this with the community and
       get feedback and suggestions to shape this project! I think that
       "remote work" is directionally correct, because we can now have
       extremely long-running coding tasks. But I also think we should be
       able to control and orchstrate that experience according to what we
       need.  The project is 100% open-source, and i hope to shape it
       together with others who like to work in this way too!  Github:
       https://github.com/wavyrai/tmux-ide Docs:
       https://tmux.thijsverreck.com/docs
        
       Author : thijsverreck
       Score  : 48 points
       Date   : 2026-03-18 17:46 UTC (5 hours ago)
        
 (HTM) web link (tmux.thijsverreck.com)
 (TXT) w3m dump (tmux.thijsverreck.com)
        
       | bwestergard wrote:
       | Looks like a great implementation. I want to question the basic
       | user story, which seems to be: "I am a software developer who
       | wants to improve productivity by running multiple simultaneous
       | agents that are roughly isomorphic to a human software developer
       | team."
       | 
       | I am burning a lot of tokens every day at work and on personal
       | projects. It's helpful. I generally work in tmux with github
       | copilot in one pane, and a few other terminal panes showing tests
       | and current diff.
       | 
       | I find it really important to avoid the temptation to multi-task
       | by running multiple agents. For quite varied tasks, productivity
       | gains from multi-tasking have proven to be illusory. Why would it
       | be different with writing software?
       | 
       | https://en.wikipedia.org/wiki/Human_multitasking
        
       | theturtletalks wrote:
       | I'm also trying to build something similar for agent
       | orchestration where one terminal is controlling multiple
       | terminals. I tried using tmux but it's very good at sending the
       | initial text to the tmux sessions, but I've not been able to get
       | an agent to have a proper back and forth controlling multiple
       | tmux sessions. I know we can use send-keys, but reading the
       | session or knowing when that session is complete is kind of up in
       | the air. And then if the main orchestrator terminal has checked
       | all the sessions to see if they're actually working and doing
       | things, the main session kind of stop so I've kind of been
       | thinking about a cron that periodically checks in and nudges it
       | to check the sessions again. Are they still working? Do they need
       | more guidance? Essentially having one terminal control others,
       | but having that back and forth with the terminals has been pretty
       | challenging to achieve. Have you gotten anywhere with this?
        
         | SparkyMcUnicorn wrote:
         | It sounds like maybe you haven't seen agent teams mode, which
         | this project is using.
         | 
         | https://code.claude.com/docs/en/agent-teams
        
           | thijsverreck wrote:
           | yup core to this project!
        
           | theturtletalks wrote:
           | Oh will definitely look into this! I ditched CC for Pi a few
           | months ago so maybe there's an equivalent feature.
        
         | sethd wrote:
         | I recently built something just like this:
         | https://github.com/sethdeckard/atria
         | 
         | It supports tmux, but you can use it without via embedded
         | terminal. It also has native integration with a few select
         | terminals that expose the right kind of APIs.
         | 
         | Installs as single binary (written in Go) with no external
         | dependencies.
        
       | garymiklos wrote:
       | I built a very similar one that I use every day, smux:
       | https://github.com/gergomiklos/smux. Took only 1 hour with
       | claude.
        
       | mlboss wrote:
       | Can somebody develop a mobile app that natively supports tmux
        
         | deadbabe wrote:
         | For all the hype of AI agents, you never see people taking on
         | _real_ challenging projects like this. Just low hanging fruit.
        
         | jrop wrote:
         | I assume that you've tried Termux and somehow that doesn't meet
         | your needs? (Also, you didn't specify whether you are on
         | Android/iOS)
        
         | thijsverreck wrote:
         | both ish and termux are great options on mobile/iPad!
        
       | 0dayman wrote:
       | https://cmux.com/
        
         | thijsverreck wrote:
         | I love cmux! ironically you can use tmux-ide within cmux. The
         | idea is to make it an agent development environment that's
         | great when ran on a remote machine :).
        
       | cyrusradfar wrote:
       | Congrats on getting this out. What was the most surprising part
       | of the build?
        
         | thijsverreck wrote:
         | most surprising was that something this lightweight made such a
         | big impact on my productivity. its really nice to have
         | persistent Claude teams on my remote machines that I can always
         | access no matter what.
        
       | quanwinn wrote:
       | I'm so married to my existing tmux workflows and layout that I'm
       | not sure whether I'd ever feel open to trying out something like
       | this. At the same time, orchestrating multiple agents with native
       | tmux and git worktree does feel cumbersome.
        
         | thijsverreck wrote:
         | if you want you can file an issue with your current workflow?
         | happy to see if we can do a PR to support this natively in
         | tmux-ide
        
         | TheRoque wrote:
         | What tools do you use on tmux to achieve your workflow ? Do you
         | do just prompting or do you code too ?
        
       | ekropotin wrote:
       | So basically tmuxinator?
        
       | operatingthetan wrote:
       | If this supported Gemini and Codex I would find it useful. I
       | never run more than one Claude, it's always a mix.
        
         | thijsverreck wrote:
         | Both are supported! You can customize the startup command in
         | ide.yml. I will update the docs to highlight that :)
        
       | selixe_ wrote:
       | Interesting, but I wonder if this shifts too much complexity onto
       | the user.
       | 
       | tmux is powerful, but not exactly approachable, and "multi-agent
       | orchestration" on top of it feels like something that could get
       | hard to reason about quickly. Curious how you think about UX
       | here.
        
         | thijsverreck wrote:
         | Good points and indeed thinking about this quite a bit.
         | Currently leaning towards a CLI first approach so that
         | Claude/Cursor/[insert coding agent] can configure and control
         | the ide. Feels a bit meta, but also makes it extremely user-
         | friendly.
        
         | j45 wrote:
         | Tmux is pretty easy to pick up and build muscle memory by
         | learning a few keyboard shortcuts from a basic youtube video
         | and it's handy when you don't want to switch screens between
         | multiple terminals just for one thing.
         | 
         | The ability to split and divide the screen pretty simply with a
         | few keys is handy for anyone who spends enough time in a shell
         | - the abilty to save that layout for the shell items you're
         | using to load up easily again the next time is valuable too.
         | 
         | Multi agent orchestration likely just means keeping track of a
         | few different windows all on one screen.
        
       | devcraft41 wrote:
       | Terminal-first makes a lot of sense for anything that runs on
       | remote servers. I've been on helix+tmux for about a year and the
       | main friction is onboarding teammates who are VSCode-native. Nice
       | to see projects pushing in this direction. Does it handle multi-
       | pane debugging or is that still a manual tmux split?
        
       | AtxWrk70 wrote:
       | the token costs are real. we switched to smaller models for 80%
       | of tasks and barely noticed
        
       | jamesvzb wrote:
       | open source alternatives are catching up fast. give it 6 months
        
       | desireco42 wrote:
       | Thank you for sharing your work. Really cool.
       | 
       | From my perspective, this is cool, but since tmux is kind of
       | permanent, you open your layout, set 1,2,3 screens for agents,
       | you might add gemini and opencode. then open vite for server and
       | one for shell for example. Then you can just close it and reopen
       | whenever you want to work on it.
       | 
       | And that is it. If I am missing something, processes taking
       | memory or such, I have a machine with memory (I know, flexing how
       | expensive things are), please explain.
        
       | behrlich wrote:
       | https://github.com/ehrlich-b/wingthing Here's my take on this
       | idea, also FOSS. Does tmux style sessions so you can come and go.
       | It also exposes a web terminal so you can get remote access - but
       | you can also run fully locally for less latency.
        
       ___________________________________________________________________
       (page generated 2026-03-18 23:00 UTC)