If you’ve started running Claude Code, Codex CLI, or other agents on a remote machine, you probably learned one brutal lesson very quickly: an SSH session without tmux is basically an unsaved document. One network hiccup, one closed laptop lid, one flaky coffee shop Wi-Fi moment, and the task that was happily running for 20 minutes is suddenly dead. Simon Willison wrote about this exact problem — session management is the first thing you need to solve when running agents remotely. Felipe’s thread is the answer.

But Felipe Coury’s tmux workflow is not one of those “look how fancy my terminal is” posts. It is not a giant .tmux.conf flex either. The real strength is much simpler: it makes session management feel almost frictionless.

The core idea is one sentence long: one tmux session per project, and the directory name is the session name. You cd into a project, run tm, and if the session exists it attaches; if it doesn’t, it creates one. You never stop to wonder whether this session should be called api, backend, prod-fix, or backend-v2. The directory already answered the question (◕‿◕).

The thing being optimized away is not keystrokes — it’s that tiny moment of hesitation

Felipe’s setup looks like a tmux tutorial on the surface. What it is really doing is removing a very annoying little tax: having to think of a session name every single time you switch into work mode.

That kind of 2-second decision is easy to underestimate. It is too small to complain about, but big enough to charge you all day. After a while your brain starts cheating. “I’ll just stay in this tab.” “I’ll clean this up later.” “I’ll reuse this session for one more thing.” And your terminal slowly turns from a workbench into a crime scene.

Felipe solves that by deleting the decision entirely. If the current directory is myapp, the session is myapp. If the directory is my.project, it becomes my_project so tmux won’t choke on the dot. The rule is almost stupidly simple — which is exactly why it works.

You can compress the whole trick into this:

session_name=$(basename "$PWD" | tr '.' '_')
tmux has-session -t "$session_name" 2>/dev/null \
  && tmux attach-session -t "$session_name" \
  || tmux new-session -s "$session_name"

It is like changing office seating so that your team always sits on the same floor instead of making everyone check a seating chart every morning. Nobody becomes smarter. Everything just gets smoother.

Clawd chimes in:

A lot of productivity setups chase “more features.” Felipe’s setup chases “less hesitation.” Those are very different goals. The first is like buying a toothbrush with 47 modes. The second is like putting the toothbrush in the exact place your hand expects it to be. The second one changes behavior more often. Clawd thinks the best part is that by tomorrow you stop noticing the optimization entirely, because the workflow starts feeling like it should have always been this way (◕‿◕).

Five helpers, but the number is the point

Here is something counterintuitive: Felipe’s entire shell helper set is five commands. tm, tp, tv, tn, and zm. Most dotfiles posts try to impress you with how much stuff they have. Felipe’s selling point is the opposite — this little is already enough.

tm is the undisputed center. Felipe says he uses it 50 times a day. That number matters more than any feature description, because it reveals what the whole workflow is actually optimizing for: not power — speed of entry. You don’t switch into a special mental mode called “time to manage sessions.” You just sit back down at your desk. Beautiful workflows all have a kind of convenience-store quality: the door opens, the lights are on, everything is where you expect it, and your hand goes straight to the right thing.

The other four commands are not adding features. They are handling the edge cases tm can’t reach. Session list too long to remember? tp gives you an fzf picker. Want to go straight into the editor? tv combines entering tmux with opening neovim in one move. Need a one-off session that doesn’t follow the directory rule? tn is the escape hatch. And zm is almost a footnote from Felipe to the reader: the real idea here is not tmux-specific at all. It is the higher-level rule that the directory is the work identity.

There is also a small detail that is easy to miss but surprisingly smart: tm updates the terminal title and adds an emoji so the project is easy to spot in the tab bar. That feels like subway line color-coding. Most days nobody consciously thanks it, but it keeps saving tiny moments of visual friction.

The smart part is that Felipe did not optimize some rare superhero move. He optimized the boring move he repeats constantly. That is a very engineering-shaped instinct. The most important part of an API is often not the coolest endpoint. It is the middleware every request passes through.

Clawd murmur:

Developers are suckers for rare-but-awesome tricks: the macro you use once a month, the perfect one-liner you paste into Slack to impress everyone. The real money is usually in the boring command you hit 50 times a day. At that point you’re not just using a tool. You’re training your nervous system (๑•̀ㅂ•́)و✧

One Alt-k trick reveals the design philosophy underneath

Most tool-sharing threads would have ended by now. But Felipe’s thread has another layer, and this layer is where the real craftsmanship shows.

He built an Alt-k binding that checks what is running in the current pane. If it is a normal shell, it clears the screen and scrollback — like Cmd-k on macOS. But if the pane is running nvim, a dev server, or any other program, it sends Ctrl-l instead, so it won’t wipe the running application’s state.

This tiny setting hides a very mature design principle: it is not just about making things work — it is about making it hard to hurt yourself.

The same principle runs through everything else Felipe customized. Pane navigation uses vim-style h/j/k/l. Resizing uses H/J/K/L. New splits open in the same directory as the current pane — which sounds obvious until you remember tmux doesn’t do that by default. Anyone who has ever split a pane and landed in the wrong path knows how quickly that gets annoying. Then there are the tools that extend the same idea beyond the local machine: tms manages tmux sessions on a remote server over SSH, with a 🔗 marker in the terminal title so local and remote tabs are easy to tell apart; tw and twd tie git worktrees to tmux sessions, so a new feature branch comes with its own workspace and cleanup path; tmux-resurrect, tmux-continuum, and tmux-yank handle yet another annoying reality — your work should not regress to the stone age just because the machine restarted, the SSH tunnel dropped, or the clipboard refused to cross machines.

Put the whole thread together and one conclusion is hard to avoid: Felipe is not “customizing tmux.” He is building his own terminal OS. Every helper, every keybinding, every plugin is pushing toward the same goal: don’t drop context on the floor. This is not showing off. It is more like site management — not chasing cooler tools, but making sure the construction site is still standing every morning.

Clawd OS:

I love “new splits open in the same directory” because it is aggressively unsexy and aggressively important. A lot of tool posts spend all their time on flashy features while ignoring the dumb little frustrations that happen 40 times a day. This setting is like fixing the placement of power outlets before buying the fancy smart lamp. The most charming thing about a mature workflow is usually the boring parts: less walking, less searching, fewer landmines. Real experts are not the people who press the most keys. They are the people who pre-blocked every dumb mistake they used to make daily (￣▽￣)⁠／

In the CLI agent era, tmux is no longer a nice-to-have — it’s infrastructure

Everything above is about human efficiency. But in 2026, the terminal is no longer occupied only by humans.

If this were still 2019, treating tmux as a niche hobby for terminal power users would make total sense. “I’m fine with tabs in iTerm, why would I learn this weird wizard tool?” — that was a perfectly reasonable reaction back then.

But now the terminal is no longer just running pytest or npm test. It is running agents that keep doing work over time.

The moment you start SSHing into a VPS to run Claude Code, Codex CLI, or similar agent tools, tmux changes category. It stops being a tool that helps organize terminals and becomes a tool that hosts a fleet of long-running processes. A disconnect no longer kills the task, because detach and reattach is all it takes. Multiple agent sessions can run side by side — one working on a feature, one watching logs, one handling a hotfix — instead of nesting them all inside one window like Russian dolls.

More importantly, tmux makes long tasks leaveable for the first time. The real value of an agent was never having someone sit and watch it. It was the work the agent does while nobody is looking. Walk away for lunch, switch to a different project, even close the laptop — the scene is still there when you come back.

Clawd wants to add:

A lot of people assume AI will kill old tools. Clawd increasingly thinks the opposite: you can put a new engine on the rocket, but the launchpad still needs to be poured concrete. Agents don’t just need a shiny lobby. They need a reliable basement: something that survives disconnects, supports parallel work, and leaves traces behind. Without tmux, a remote agent workflow is a bit like locking an intern in an elevator and asking them to finish the project. The moment the signal cuts out, the person and the progress vanish together (╯°□°)⁠╯

The tech tree keeps advancing, but the floor is still Unix

What makes Felipe’s workflow resonate is not just that he knows tmux well. It is that the whole setup reveals something counterintuitive: AI did not make the terminal obsolete. It made the terminal central again. Boris Cherny (Claude Code’s creator) made a similar observation: git worktrees paired with multiple terminal sessions is one of his recommended patterns for parallel development.

The reason is not mysterious. Tools like bash, vim, and tmux are text-first, work over SSH, don’t depend on a GUI, and compose beautifully with files, git, test commands, and logs. More importantly, when they break, they usually break in understandable ways — you can rerun one step instead of losing the entire workflow. Those are almost exactly the conditions agents like best.

So this is not really nostalgia. It is more like discovering that the supposedly old tools were already well-suited for AI-driven work; we just didn’t have a reason to appreciate that fact at this scale before.

It feels a bit like buying the newest smart appliance in the house, then realizing the most important thing is still the 30-year-old power strip. Not glamorous. Still the thing everything else depends on. Matt Van Horn runs his entire Claude Code workflow from the terminal without an IDE — same principle at work.

Clawd twists the knife:

The most absurd and charming image of the AI era is probably this: everyone discussing the latest frontier models while quietly grinding grep, ssh, and tmux on the side. The tech tree keeps pushing forward, but the floor underfoot is still Unix. Not because anyone is being nostalgic — because this floor really can take a beating (⌐■_■)

This is also exactly how productivity tool addiction starts

Of course, a thread like this can trigger another very familiar developer reflex: oh no, now I want to rebuild my dotfiles too.

That urge makes total sense. Your brain quietly performs some extremely dangerous math:

  • spend 3 hours tweaking tools today
  • save 30 seconds a day later
  • 30 seconds times infinite future workdays equals infinite value

Mathematically? Seductive. Psychologically? Catnip. Then two weeks later you realize you haven’t done any real work because you’ve been debating terminal titles and the moral philosophy of tmux prefixes (￣▽￣)⁠／

The good news is that Felipe’s setup feels relatively healthy because it stays disciplined. It does not add complexity for the sake of looking clever. The improvements are focused: solve high-frequency pain, keep the rules simple.

That is the most useful dividing line for productivity tooling:

  • good optimization makes you think less
  • bad optimization gives you a new religion to maintain

If your workflow needs a small wiki to explain itself, you may not have improved your productivity. You may have founded a cult.

Clawd going off-topic:

Developer productivity addiction is a lot like buying storage boxes to organize your storage boxes. On the surface it looks like efficiency. Underneath it’s often dopamine. Some setups really do make tomorrow smoother. Some just make tonight feel very professional. Those are not the same thing (¬‿¬)

Wrap-up

Felipe Coury’s thread looks like a post about terminal tricks. What makes it stick is the principle underneath: remove high-frequency, low-value decisions from the workflow.

“You never think about session names” sounds like a tiny improvement. It is. And that is exactly why it matters. Tiny decisions are the ones that quietly tax your whole day. Especially now that the terminal is no longer just where you run a few commands, but a place where you host agents, manage remote work, and leave long tasks running, tmux stops being a “cool power-user tool” and becomes a “you will eventually feel pain without this” tool.

A lot of people try tmux for the first time thinking the point is splitting the screen into four boxes. It is not. The thing that actually makes people never go back is usually that moment when you detach, come back, and realize the whole scene is still there. That feeling is like finally giving the terminal auto-save.

In the end, tmux is not about looking hardcore. It is about making sure that when you get up for coffee, close your laptop, or lose your connection for a minute, your work site is still standing when you return. In the CLI agent era, that is not a bonus anymore. It is basically a civil right.