DEV Community: Glenn all

Tmux is the Missing Operating System for AI Coding Agents

Glenn all — Wed, 12 Aug 2026 06:43:11 +0000

You're running two AI agents in parallel on the same codebase. One implements a feature. The other reviews it. A test watcher sits in the corner. Logs stream somewhere. You close your laptop to grab coffee. SSH drops. You open it back up, and half of it is gone.

This is what happens when you try to scale from "one developer, one command, wait for it to finish" to "multiple agents doing different things at once." Your tools assume serial work. Your actual problem is parallel supervision.

The article "Tmux Is The Missing Operating System For AI Coding Agents" maps out why this happens and what actually fixes it. The fix isn't a fancy orchestration platform. It's tmux, a terminal multiplexer that's been doing this job well for fifteen years.

But here's the part that matters: the article doesn't just explain tmux. It shows the specific supervision gaps that emerge when you move from sequential to parallel agent work, and it walks through a concrete workflow that closes those gaps without adding infrastructure you don't need yet.

The Fundamental Shift in Your Job

When you ran code yourself, your job was writing every line. When you run AI agents, your job is different: define tasks, allocate context, supervise parallel work, review results, recover processes that failed while you weren't looking.

That requires a different kind of visibility. Not just "can I see the code" but "can I see what's happening across four simultaneous processes right now, and can I interrupt any of them instantly if something's wrong?"

Terminal tabs give you visibility. They don't give you persistence or clear boundaries. The moment your SSH connection drops, everything you were watching disappears.

Why Parallel Work Breaks Terminal Tabs

One developer. One command. Wait for it to finish. Move on. That's the model terminal tabs were built for.

Parallel agent work breaks it in three specific ways:

Agents work at the same time instead of sequentially. An implementation agent, a review agent, a test watcher, a dev server, all alive at once, not one after another.

Processes run long. They need to stay visible for as long as they're generating output. Not for two seconds. For hours.

Everything needs continuous visibility. Logs, test output, diffs, error traces. Not buried in scrollback you lost twenty minutes ago.

Terminal tabs organize what you can see right now. They don't organize what keeps running after you look away.

Three Concepts, Nothing More

tmux has three concepts:

A session is a persistent workspace. It keeps running whether you're looking at it or not. Close the terminal window, lose the SSH connection, switch machines entirely. The session stays alive.

A window is a tab inside that session, usually one project or one task.

A pane is a single split inside a window, running one process.

You detach from a session and it keeps going in the background. You reattach later and get the exact terminal state back, scrollback included.

tmux new-session -s ai-workspace
tmux split-window -h # split vertically
tmux split-window -v # split horizontally
tmux detach # leave the session running
tmux attach -t ai-workspace # come back to exactly where you left off

That's most of what you need. The persistence is the actual feature.

What Parallel Supervision Actually Requires

You need to see four things at once: what one agent is doing, what another agent thinks about it, whether the tests pass, and what's happening at runtime.

That's four panes with defined jobs:

Pane 1: primary agent implementing one scoped change.
Pane 2: independent review agent spotting regressions, not writing code itself.
Pane 3: test watcher running continuously.
Pane 4: server and runtime logs, so you see the effect of changes as they land.

Your job becomes narrower than either agent's. Approve decisions. Resolve disagreements between what the two agents report. Decide what gets merged. Read the diff yourself before accepting anything.

Without this separation, more agents just means more noise.

The Isolation Problem tmux Doesn't Solve

tmux solves where processes run. It does nothing about two agents editing the same files on the same branch at the same time. That's a bigger source of chaos than any terminal layout.

The answer is git worktrees:

git worktree add ../project-api -b feature/api
git worktree add ../project-review -b review/api

One tmux window per worktree. Each agent has its own filesystem view. Zero risk of stepping on another agent's uncommitted changes.

tmux isolates processes and views. Git worktrees isolate code. You want both. They solve different problems.

This matters more than it sounds. The most common failure mode in parallel agent work isn't terminal layout. It's two write-enabled agents in one worktree, creating conflicting edits that take longer to untangle than either agent saved you.

Script the Layout, Don't Rebuild It

Rebuilding a six-pane setup by hand every morning gets old around day three.

#!/usr/bin/env bash
tmux new-session -d -s ai-project -n agents
tmux split-window -h -t ai-project:agents
tmux new-window -t ai-project -n tests
tmux new-window -t ai-project -n server
tmux attach -t ai-project

Save it, commit it next to your project. The layout becomes something you version instead of something you reconstruct from memory.

A minimal config worth adding on top:

set -g mouse on
set -g history-limit 50000
set -g status-left "#[bold]#S "
bind h select-pane -L
bind l select-pane -R
bind j select-pane -D
bind k select-pane -U

The scrollback bump matters. Agent output and error traces from twenty minutes ago disappear fast at the default limit. Re-asking an agent something it already told you wastes both your time and its context window.

Persistence: The One Thing That Actually Matters

Closing the terminal window. SSH dropping mid-task. Wi-Fi cutting out. Switching machines. A 40-minute agent run you don't want to babysit.

Without tmux, any of these kill your work. With it:

tmux detach
tmux list-sessions
tmux attach -t ai-workspace

The interface disappears. The work doesn't.

One caveat: this is process-level persistence, not machine-level. Reboot the host and the session goes with it. If work has to survive a full restart, you need something on top, a supervisor process or a restoration script.

What tmux Explicitly Doesn't Cover

tmux is a control layer with visibility, interrupt capability, and clear boundaries between concurrent tasks. It has no concept of tasks, dependencies, permissions, or success criteria. It doesn't know what an agent is.

The judgment about what should run, in what order, who's allowed to touch what, that's still you.

And critically: an agent with filesystem write access inside a tmux pane has exactly the access it would have outside one. tmux is not a security boundary. Treat it as one and you'll find out the hard way. Pair it with real isolation: tmux plus git worktrees plus containers plus scoped agent permissions. Each layer does the one thing it's actually good at.

When to Skip This Approach

A single short-lived agent task doesn't need a persistent multi-pane workspace.

Work that has to survive a full machine reboot needs something tmux doesn't give you. Multi-user orchestration or agents spread across several machines calls for real infrastructure: CI pipelines, Kubernetes jobs, a dedicated agent-ops tool.

Anywhere you need actual security or resource isolation, tmux is the wrong layer. That's what containers exist for.

Start Here

One session. Four panes. An agent, a server, your tests, your logs. Detach, walk away, come back to a workspace exactly where you left it.

Plain terminal tabs feel surprisingly fragile after that.

pub.towardsai.net

how to use react context?

Glenn all — Sun, 04 Dec 2022 12:01:08 +0000

React's Context API allows you to share values such as state or data between components without passing props down manually through every level of the component tree. This can be especially useful when you have some values that are needed by many components in your application.

To use the Context API, you first need to create a context using the createContext() method from the react package. This method returns an object with two components: Provider and Consumer.

import { createContext } from 'react';

const MyContext = createContext();

The Provider component is used to provide a value for the context, which can then be consumed by the Consumer component. The Provider component should be placed at the root of your component tree, wrapping the components that need access to the context value.

import MyContext from './MyContext';

function App() {
  return (
    <MyContext.Provider value="Hello World">
      <MyComponent />
    </MyContext.Provider>
  );
}

In the example above, the value "Hello World" is provided for the MyContext context. This value can then be consumed by the MyComponent component, or any other component nested inside it, using the Consumer component.

import MyContext from './MyContext';

function MyComponent() {
  return (
    <MyContext.Consumer>
      {value => <p>{value}</p>}
    </MyContext.Consumer>
  );
}```



The Consumer component expects a function as its child, which will be called with the current context value. The function should return a React element that uses the context value. In the example above, the context value is used to render a p element with the value inside it.

You can also use the useContext() hook from the react package to consume the context value inside a functional component.



```js
import { useContext } from 'react';
import MyContext from './MyContext';

function MyComponent() {
  const value = useContext(MyContext);
  return <p>{value}</p>;
}

The useContext() hook takes the context object as its argument and returns the current context value. You can then use this value inside the component.

It's also possible to update the context value using the useState() hook inside a component that is a descendant of the Provider component. This can be useful for implementing state management using the Context API.

import { useContext, useState } from 'react';
import MyContext from './MyContext';

function MyComponent() {
  const [value, setValue] = useState(useContext(MyContext));

  function handleClick() {
    setValue('Hello World!');
  }

  return (
    <>
      <p>{value}</p>
      <button onClick={handleClick}>Update Value</button>
    </>
  );
}

In the example above, the context value is initially set to the value provided by the Provider component using the useContext() hook. A button element is then rendered with an onClick event handler that updates the value using the setValue() function from the useState() hook

what is service discovery? (example provided)

Glenn all — Sun, 04 Dec 2022 11:13:35 +0000

Service discovery is a process by which services that are available on a network are identified and located. This can be useful in distributed systems, where multiple services may be running on different machines and need to communicate with each other.

Service discovery typically involves the use of a discovery service, which maintains a list of available services and their locations on the network. Clients can query the discovery service to find the location of a specific service, and then connect to that service directly to access its functionality.

Service discovery tools

There are many tools that can be used to implement service discovery in a distributed system. Some common tools include:

Consul: Consul is a tool for service discovery and configuration management in distributed systems. It provides a simple and effective way to locate services and manage their configurations.

Zookeeper: Zookeeper is a distributed coordination service for distributed applications. It provides a centralized registry for services, allowing clients to discover and connect to the services they need.

Eureka: Eureka is a service registry for the Netflix OSS ecosystem. It provides a way for services to register themselves and for clients to discover and connect to the services they need.

etcd: etcd is a distributed key-value store that can be used for service discovery. Services can register themselves by storing their metadata in etcd, and clients can discover and connect to the services they need by querying etcd.

Kubernetes: Kubernetes is a container orchestration platform that provides built-in support for service discovery. Services can be registered with Kubernetes and accessed using DNS or an API, allowing for easy and efficient discovery and connectivity.

Here is an example of how service discovery might be implemented using** Express.js** and Consul:

// Register the service with Consul
consul.register({
  name: "service-name",
  port: 8080,
  check: {
    http: "http://localhost:8080/health",
    interval: "10s"
  }
});

// Create an Express.js app
const app = express();

// Register the service with Express.js
app.register("service-name", {
  port: 8080,
  check: {
    http: "http://localhost:8080/health",
    interval: "10s"
  }
});

// Start the Express.js app
app.listen(8080); ```

`

In this example, the service is registered with both Consul and Express.js, providing a way for clients to discover and connect to the service using either tool. Consul is also used to manage the service's configuration, allowing for dynamic updates without requiring a restart.

what is microservice architecture?

Glenn all — Sun, 04 Dec 2022 10:10:11 +0000

Microservice architecture is a design approach for building software systems that are composed of small, independent, and modular components, known as microservices.

Each microservice is designed to perform a specific function or set of related functions, and can be developed, deployed, and maintained independently of the other microservices in the system. This allows for flexibility, scalability, and resiliency, as the system can be easily adapted and evolved to meet changing requirements.

Example of microservice:

let's define a simple microservice that exposes a single endpoint /add which accepts two numbers as query parameters, a and b, and returns the result of adding them.

tech stack Express

const express = require('express');
const app = express();

// A simple function that adds two numbers
function add(a, b) {
  return a + b;
}

// Define an endpoint that accepts two numbers
// and returns the result of adding them
app.get('/add', (req, res) => {
  const a = parseInt(req.query.a);
  const b = parseInt(req.query.b);
  const result = add(a, b);
  res.send({result});
});

// Start the server on port 3000
app.listen(3000, () => {
  console.log('Microservice listening on port 3000!');
});

To run this microservice, you would need to install the required dependencies, such as Express, and then start the server by running the code. Once the server is running, you can send HTTP requests to the /add endpoint to test it out. For example, you could use the following curl command to send a request to add 2 and 3:

curl 'http://localhost:3000/add?a=2&b=3'

This would return the following response:

{"result":5}