wdx | Blog

Four ways running several AI agents goes wrong, and how wdx fixes each

Fri, 13 Nov 2026 00:00:00 GMT

Running one AI coding agent is exciting; running three or four at once is where the developer experience falls off a cliff. Before you know it, you are juggling disappearing terminal tabs, clashing file edits, silently blocked agents waiting on input, and a chaotic mess of mystery diffs.

Most developers start by opening a handful of terminal tabs or tmux splits, firing up Claude Code, Codex, or Cursor in each, and hoping for the best. Within an hour, concurrency breaks down into confusion:

“agent waiting on response while i’m thinking that the work is progressing happened multiple times, and while running multiple agents manually it happened many times that multiple agents started working in main branch and interfered with each other’s work, moreover, not able to close terminal or shutdown/restart computer for days event months so that the curren work/context is not lost but with wdx i can resume working from where it left”

Here are the four classic failure modes of running multiple AI coding agents from plain terminals, why each happens, and the architectural primitives wdx uses to fix each.

Running multiple AI agents in plain terminals leads to lost sessions, clashing checkouts, silent stoppages, and mystery diffs. wdx solves each with an architectural primitive.

Failure 1: The Disappearing Session (Lost Terminals)

The problem

When you run an AI agent inside a standard terminal window, tab, or SSH connection, the agent process lives and dies with that pseudo-terminal (PTY) session. If you accidentally close the tab, if your window manager crashes, if an SSH connection times out, or if your laptop forces a reboot, the process terminates abruptly.

Because of this vulnerability, developers develop coping mechanisms:

Leaving terminal windows open for weeks or months at a time, dreading any reboot or system update.
Cluttering the taskbar with dozens of minimized windows out of fear that closing one loses an agent’s active conversation state.
Losing half-finished refactorings when a laptop battery dies or network connection resets.

How wdx fixes it: Daemon-Managed PTY Holders

In wdx, agents do not run inside your terminal emulator. They execute inside dedicated background holder processes managed by a local background daemon:

Process decoupling: The holder owns the PTY, the screen buffer, and the child agent process. When you attach with wdx agent attach or view agents in TIDE, you connect to the holder over a Unix socket. Disconnecting (C-\ d) or closing your terminal window leaves the agent running unaffected.
Reboot recovery via lost state: Even if your entire machine restarts or the daemon stops, wdx tracks the agent’s identity, directory, worktree, and ACA session in its database. When the daemon restarts, the agent appears in wdx agent list as lost. Running wdx agent start --name <name> re-attaches to the exact ACA session and resumes work with full conversation context intact.

Detached PTY holders outlive terminal windows, crashes, and reboots. Re-launching brings the agent straight back into its session.

Failure 2: The Stepped-On Source Tree (Clashing Edits)

The problem

A git repository checkout has exactly one working tree and one staging index (.git/index). When you launch multiple agents from the root directory of your project, they all operate on the exact same checkout on main.

What follows is an inevitable train wreck:

Overwritten edits: Agent A modifies notes.py while Agent B is analyzing or rewriting the same file. One agent’s half-finished logic overwrites the other’s.
Corrupted staging index: Agent A stages files for a commit; Agent B runs git commit or stages unrelated changes, bundling both features into an unparseable franken-commit.
Tangled git status: You check the status of your branch and have no idea which modified file belongs to which agent’s prompt.

How wdx fixes it: Isolated Git Worktrees

wdx solves this at the filesystem level using git worktrees. Passing --worktree <name> to wdx agent create automatically creates a dedicated worktree in .worktrees/<name> branched from HEAD:

Terminal

wdx agent create --name notes-delete --worktree notes-delete --aca claude_code \
  --prompt "Add delete command"
wdx agent create --name notes-search --worktree notes-search --aca codex \
  --prompt "Add search command"

Each agent gets:

Its own working directory: File modifications happen in complete physical isolation under .worktrees/.
Its own git index and branch: Each agent commits to its own dedicated branch. Staging or committing never interferes with other agents.
A pristine main tree: Your repository’s main checkout remains 100% clean while multiple agents work concurrently in the background.
Zero repository lock contention: wdx commands read worktree state without taking repository locks, allowing background monitoring to run alongside active git operations.

Each agent works in an isolated git worktree with its own branch and index. The main branch stays completely clean.

Failure 3: The Silent Stoppage (Unanswered Prompts)

The problem

Of all the failure modes in multi-agent workflows, unanswered prompts are the single biggest productivity killer.

You prompt three agents with complex tasks, feel a surge of productivity, and switch to a different screen—reviewing architecture docs or attending a meeting. You assume the agents are deep in execution: parsing files, running tests, refactoring modules.

In reality, ninety seconds after you switched windows, Agent 2 paused to ask a routine confirmation question:

“Do you want to run npm test? (y/N)”
“File schema.prisma already exists. Overwrite? [Y/n]”
“Do you trust this folder to execute tools? (yes/no)”

Because plain terminal tabs have no notification mechanism, the agent sits completely idle. Forty-five minutes later, you check back expecting a finished implementation, only to find the agent blocked on a prompt that required a single keystroke.

Multiply this across three or four agents and your multi-agent concurrency collapses. You spend more time manually babysitting and polling terminal tabs than building software.

How wdx fixes it: Real-Time VT Screen Parsing & Amber TIDE Badges

wdx turns silent stops into immediate, actionable visual alerts:

Headless Virtual Terminal (VT) screen engine: wdx runs a headless VT state machine for every agent’s PTY. Instead of polling process exit codes or scraping logs after the fact, wdx parses the terminal output stream in real time. It reliably classifies agent activity into three canonical states: working, idle, or waiting on human input.
Prominent amber badges in TIDE: In TIDE (wdx tide), an agent waiting on a question turns into a bright amber row with a ? badge in the project navigator. You know the exact second an agent needs attention without hunting across tabs.
Instant in-place response: You do not need to switch terminals. In TIDE, navigate to the amber row and press o (or Enter) to open the agent’s live screen. Press the required key (e.g., y or Enter), and the agent immediately transitions from amber waiting back to green working.
Safe inbox steering: If you prefer working from scripts or the CLI, wdx agent send queues input in an agent inbox. It waits until the agent’s terminal is in raw mode and ready to accept input before pasting, preventing garbled or dropped keystrokes. Using --instant immediately interrupts or prioritizes your input.

VT screen parsing catches prompts instantly. TIDE flags the agent in amber with a ‘?’ badge, allowing you to answer in seconds.

The problem

An agent reports: “I have finished adding the search command and all tests pass.”

What did it actually touch? In a traditional terminal workflow, verifying the agent’s work is surprisingly painful:

You have to manually run git diff <branch>..main in a separate shell.
If the agent modified multiple files, you have to scroll through raw terminal diffs or open an external GUI diff tool.
If you notice a minor mistake, you have to craft a follow-up prompt, switch back to the agent’s tab, and explain line-by-line what needs fixing.
When you are ready to integrate, running git merge often introduces unwanted merge commits or undetected regressions.

How wdx fixes it: In-Tab Diff Review & Guarded Landing

wdx integrates diff review and landing directly into the development workflow:

In-tab visual diff (o): In TIDE, selecting a worktree and pressing o opens a color-coded unified diff tab right beside your agents. You can inspect additions, deletions, and modified files with zero context switching.
Inline line commenting (c and s): When reviewing an agent’s diff, press c on any line to leave a comment. Press s to batch-dispatch your review comments back to the agent’s inbox as concrete revision requests.
One-key guarded landing (L): When the diff looks good, press L. wdx automatically runs your project’s configured pre-landing test checks (via wdx project landing), rebases the commits onto main with a clean linear history, and prompts you to remove the temporary worktree.

Review diffs visually in TIDE with ‘o’, then land with ‘L’. wdx runs test checks and rebases linearly onto main with zero merge commits.

Comparison Matrix: Plain Terminals vs. wdx

Failure Mode	Plain Terminal Tabs	wdx Architecture
Lost Terminals	Window crash or reboot terminates PTY; sessions lost permanently	Daemon-managed PTY holders outlive terminals; resumes via `wdx agent start`
Clashing Edits	Agents collide in shared root on `main`; files overwritten & index dirty	Isolated git worktrees (`--worktree`) in `.worktrees/`; clean `main` tree
Unanswered Prompts	Agent stalls on prompt silently; hours lost with zero notification	Real-time VT screen parser flags `waiting`; amber row & `?` badge in TIDE
Mystery Diffs	Manual `git diff` archaeology; risky merge commits & broken builds	In-tab diff review (`o`), inline comments (`c`), and one-key guarded landing (`L`)

Try It

You can run your multi-agent workflow under wdx in four simple steps:

Install wdx:

Terminal

curl -fsSL https://srjn45.github.io/wdx/install.sh | sh

Open your project:
Terminal
```
cd ~/dev/my-project
wdx project open
```

Launch agents in isolated worktrees:

Terminal

wdx agent create --name feature-auth --worktree auth --prompt "Implement JWT token validation"
wdx agent create --name feature-docs --worktree docs --prompt "Update API documentation in docs/"

Open TIDE to steer your fleet:
Terminal
```
wdx tide
```

Quit TIDE anytime with C-q q. Your agents keep executing in the background, their checkouts remain isolated, and any waiting prompt is always flagged before it stalls your day.

A tour of TIDE, the terminal IDE for AI agents

Thu, 12 Nov 2026 00:00:00 GMT

Running multiple AI coding agents from raw terminal tabs quickly turns into a blind juggling act: you can’t tell who is waiting on a prompt, whose git diff is whose, or which agent is silently burning through its context window.

TIDE—wdx’s Terminal IDE—pulls your entire agent fleet into one window: agents, worktree diffs, code, docs, plans, and shells, with zero context switching and no mouse required.

The problem with terminal tabs

When you run three or four AI coding agents across multiple terminal windows or tabs, friction compounds rapidly:

“i use gnome terminal on my ubuntu and iTerm2 on mac on daily basis”

In traditional workflows across GNOME Terminal or iTerm2, running multiple agents usually means:

Invisible blockers: An agent stops in tab 4 to ask whether it should run a database migration or install a package. Unless you actively cycle through every tab, it sits idle for twenty minutes waiting for a simple yes.
Context fragmentation: You lose track of which branch belongs to which prompt, and inspecting an agent’s changes requires leaving the conversation to run manual git diff commands in a separate shell.
Lost sessions: If your terminal closes, SSH drops, or your laptop sleeps, interactive agent sessions running directly in foreground tabs often die abruptly.

TIDE (wdx tide) is designed specifically around how AI coding agents work. Built directly into the wdx binary, TIDE is an interactive Bubble Tea terminal application that talks to the local background daemon. Agents and shells run in daemon-managed PTY holders—not inside your terminal window. Quitting TIDE leaves every agent working uninterrupted, and reopening wdx tide restores your exact layout, open tabs, cursors, and running processes.

The three-pane layout

TIDE replaces ad-hoc tab sprawl with a purposeful three-pane layout that dedicates space to project navigation, agent interaction, and system shells:

TIDE's three-pane layout: a 1/4 project navigator on the left, a 3/4 multi-tab agent workspace on the right, and a docked terminal drawer below toggled with C-\.

The interface is structured into three distinct zones:

The Project pane (left, 1/4 width): Your project’s central navigator. It organizes your work into five collapsible sections: Agents, Worktrees, Plans, Docs, and Code. You can reorder or toggle any section with the tide.section_order setting.
The Agent workspace (right, 3/4 width): A tabbed canvas where live work happens. Each tab holds a live agent PTY, a git diff, a rendered Markdown doc, an interactive task graph, or an in-tab terminal editor.
The Terminal drawer (bottom, 1/4 docked height): Project terminals and test runners docked at the bottom. Toggle it into view or hide it instantly with C-\.

Key interception philosophy

Because agents and terminal editors require direct keystroke passthrough, TIDE takes almost zero global keys for itself:

Shortcut	Action
`Alt+←` `Alt+→`	Cycle focus between the project pane and open workspace tabs
`Alt+↑` `Alt+↓`	Jump into the docked terminal drawer and back to the active workspace
`C-]`	Zoom the focused pane to fill the entire window (and back)
`C-\`	Toggle the terminal drawer open or closed
`C-q`	Open the single-letter contextual action menu
`C-q q`	Quit TIDE (all background agents and holders keep running)

In the project pane, single letters dispatch common actions directly without C-q: a creates a new agent, t opens a new terminal, s jumps to settings, / starts fuzzy filtering, and q exits. Inside agent and shell panes, every single keypress is forwarded untouched to the underlying program.

Mouse support and persistence

While optimized for keyboard navigation, TIDE includes full mouse support:

Click any pane to focus it, or click a row or tab to select it.
Scroll through conversation histories, diffs, and files with the mouse wheel.
Double-click any pane’s frame (or its [⤢] indicator) to toggle full-screen zoom.
Click and drag text within any pane to select and copy directly to your system clipboard via OSC 52.

The full agent lifecycle

The core strength of TIDE is orchestrating an agent’s entire lifecycle without ever leaving your terminal:

“agents and plans, mostly the ease of use with tide makes life easier”

“i check the diff and leave comments for the agent”

Here is what that lifecycle looks like in action on our toy notes repository: a lead coordinator spawns a child agent in an isolated git worktree, the child writes code, you review the live diff and leave inline review comments with c, batch-send the review with s, the agent addresses the feedback live, and you land the change back to main with one key (L):

The full agent lifecycle in TIDE: parent coordinator spawns a child in a worktree, user reviews the diff and leaves inline comments (c), batch-sends review (s), agent addresses feedback, one-key land (L), and clean termination.

Here is the step-by-step loop:

Spawn child agent in a worktree: A parent coordinator agent launches a specialized child agent (count) in an isolated worktree (.worktrees/notes-count). The child appears indented under its parent (└ count) in the Agents section.
Review the live git diff: You navigate to the notes-count worktree in the project pane and press o to open its diff tab. TIDE monitors filesystem and git events via inotify—no manual refreshes needed.
Leave inline review comments (c): Position your cursor on any added or modified line in the diff and press c. A comment box pops up: type your feedback (such as “Support singular ‘1 note’ vs plural ‘N notes’”) and press Enter. The comment is pinned directly beneath the line with a ✎ indicator.
Batch-send review comments (s): Rather than interrupting the agent for each individual comment, draft multiple notes across the diff. Press s in the worktree tab to bundle all comments into a single review message dispatched to the agent’s inbox.
Agent resolves feedback and commits (C): The agent reads the review and updates notes.py. TIDE’s inotify watcher updates the live diff on screen in real time. Press C in the tab to ask the agent to commit the uncommitted changes, flipping the tab directly to the committed view with L land.
One-key atomic landing (L): With changes verified, press L inside the worktree tab. TIDE validates project landing checks, executes an atomic rebase onto main, and prompts to remove the temporary worktree.
Clean termination: Confirming worktree removal automatically ends the child agent and frees up disk space, leaving your branch clean and linear.

Answering waiting agents

AI coding agents frequently stop to ask permission before executing terminal commands or modifying sensitive files.

In raw terminal tabs, these prompts are silent stalls. In TIDE, any agent waiting on human input immediately highlights in amber:

The agent’s mark changes to ? and its status row reads yes/no or decision (for Claude Code), or waiting.
If child agents are nested under a folded parent, the parent row displays an amber N waiting badge so no child agent is overlooked.
Press Enter on the row to preview its session, or o to open the tab and switch focus directly into it.
Answer the prompt using your keyboard as you normally would. The moment the agent resumes work, the row shifts back to green working.

Browsing code & in-tab edits

Beyond diff reviews, TIDE provides a built-in Code section that lets you explore any worktree as a file tree without switching windows:

Git status annotations: Files in the tree display their git status flags (M for modified, A for added, ? for untracked).
Syntax-highlighted viewing: Press Enter on any file to open it in a syntax-highlighted read-only viewer.
Rendered Markdown (m): When viewing documentation or specs, press m to toggle between rich terminal rendering (powered by Glamour) and raw Markdown source.
In-tab terminal editor (e): Need to tweak a configuration setting or fix a typo manually? Press e to open the file inside your configured editor (vim, nvim, nano, hx, emacs) directly in a workspace tab. When you save and exit, the tab seamlessly reverts to its read-only viewer and reloads the modified contents.
Fuzzy filter (/): Pressing / in the project pane activates an instant fuzzy search that filters across all sections simultaneously—matching agents, worktree paths, doc titles, and plan tasks. Press Esc to clear.

Living docs & ASCII plan graphs

Complex multi-agent engineering requires shared context. TIDE brings project documentation and orchestration graphs directly into view:

Living architecture specs

Project docs managed via wdx doc live in the project pane’s Docs section. Each doc displays its current revision and status badge (approved, wip, review). Opening a doc renders its formatting, tables, and links cleanly in the terminal, updating automatically whenever an agent updates a spec.

ASCII plan graphs

When running multi-task features via wdx plans, TIDE visualizes the entire execution DAG:

Parallel execution slots are drawn as multi-lane graph rails (reminiscent of git log --graph).
Task rows display status marks: ✓ done, ● working, ○ waiting, or ✕ failed.
The task inspector panel on the right details the selected task’s prompt, requirements (▲), unblocked downstream tasks (▼), and execution slot.
Inspect failed tasks, trigger retries (r), pause running pipelines (p), or view task summaries without leaving TIDE.

TIDE never forces you to memorize dozens of esoteric key combinations:

The contextual menu (`C-q`)

Pressing C-q opens a single-letter action menu tailored specifically to your current focus:

On an agent: i for detailed info, c to spawn a child, r to rename, R to start a fresh session, x to remove.
On a worktree: L to land, C to ask the agent to commit, R to rebase, v to mark a file verified.
In Code: e to edit, n for new file, N for new folder, r to rename.
Global commands: a for new agent form, t for new terminal, s for settings, S for stats, q to quit.

Every menu shortcut executes immediately upon pressing its letter.

In-place settings (`C-q s`)

Pressing C-q s opens an interactive settings tab displaying every wdx configuration option:

Cycle through choices for options like tide.theme, tide.section_order, editor, and log.level using ← and →.
Press Enter on any text value to edit in place.
Changes are written atomically to ~/.wdx/config.yaml and reloaded live by the daemon without requiring a restart.

Account stats & quotas (`C-q S`)

Running fleets of AI coding agents makes tracking rate limits and account quotas essential.

Pressing C-q S opens the machine-wide Stats tab since 0.5.0, providing live usage monitoring across all supported AI CLIs:

┬─[● coordinator(-)]─[stats(-)]──────────────────────────[⤢]─┐

   claude_code:                available
     Session (5 h):            54% ▰▰▰▰▰▱▱▱▱▱  resets in 2 h 10 min
     Week:                     51% ▰▰▰▰▰▱▱▱▱▱  resets Nov 19 10:00
     as of:                    12:46

   antigravity Gemini models:  available
     Session (5 h):            12% ▰▱▱▱▱▱▱▱▱▱  resets in 4 h 02 min
     Week:                     30% ▰▰▰▱▱▱▱▱▱▱  resets Nov 20 08:00
     as of:                    12:45

   codex:                      available
     Session (5 h):            16% ▰▰▱▱▱▱▱▱▱▱  resets in 3 h 45 min

Zero overhead: TIDE extracts limits directly from the status lines and session files already maintained by each CLI. It never makes extra API requests or injects prompts into agent sessions.
Multi-window tracking: View both 5-hour rolling session windows and weekly quotas. Countdown timers update every minute.
Automated fleet badges: If a quota window is exhausted, any agent relying on that model bucket is automatically tagged with a red limited badge in the Agents list, disappearing on its own when the reset window passes.

Remote access

Need to check on an agent fleet running on your office workstation or a cloud dev machine?

wdx tide --node <name> since 0.5.0 connects to TIDE running on any node associated with your account through the self-hosted wdx hub:

wdx tide --node desk

Encrypted tunnel: Connections run over an authenticated TLS 1.3 tunnel established with CPace and your host authenticator code.
Unmistakable remote status: The TIDE status line turns bright cyan and displays the remote host prefix (desk › notes · agent), and the window title updates to wdx tide · desk. You will never confuse a remote environment with your local machine.
Host session oversight: While a remote session is connected to your machine, pressing C-q H lists active client sessions, and the status bar displays remote: <node>.

Summary & Getting Started

Managing multiple AI coding agents shouldn’t require dozens of disconnected tabs, manual diff checks, or lost terminal sessions.

TIDE consolidates your entire agent fleet into a fast, keyboard-driven terminal environment:

Monitor multiple agents and child processes in a structured tree.
Review git diffs and leave inline feedback directly where work happens.
Browse worktree files, edit documentation, and track plans in real time.
Keep tabs on account quotas and rate limits across Claude Code, Antigravity, Codex, and Cursor.

To install wdx and take TIDE for a spin:

# Install wdx on macOS or Linux
curl -fsSL https://srjn45.github.io/wdx/install.sh | sh

# Open your project in TIDE
cd your-project
wdx tide

For detailed guides and reference documentation:

Explore the TIDE Layout Guide
Learn about Worktrees and Diffs
Read about Child Agents and Orchestration
Check out the project on GitHub

Claude Code, Codex, Cursor and Antigravity under one tool

Thu, 12 Nov 2026 00:00:00 GMT

Every AI coding CLI makes its own assumptions about terminal screens, keybindings, session files, and permissions. Run four of them on the same machine and you spend more time translating between their quirks than writing code.

One tool demands alternate screens and mouse tracking; another saves SQLite databases under internal cache paths; a third expects proprietary plugin hooks for context injection; and a fourth reads developer instructions from JSONL rollout logs.

wdx treats them all as engines behind a single interface. Whether you run Anthropic’s Claude Code, OpenAI’s Codex, Cursor’s CLI agent, or Google’s Antigravity CLI, every agent operates under the same lifecycle: daemon-managed PTY holders, isolated git worktrees, screen-based state detection, non-blocking inbox queues, and unified token and quota telemetry.

The fragmentation of AI CLIs

The terminal-based AI coding assistant landscape has exploded over the past year. But having access to state-of-the-art models across different providers came with severe operational friction:

Different mental models: Each tool invents its own workflow. Some expect you to approve permissions via full-screen terminal dialogs; others require custom command-line flags. Keybindings for interrupting turns, submitting follow-up messages, or clearing context differ wildly.
Scattered session state: When an agent finishes a task, its conversation is locked inside proprietary storage—flat JSONL logs in ~/.codex/sessions/, SQLite databases in ~/.gemini/antigravity-cli/, or agent-specific chat directories in ~/.cursor/. Resuming work or extracting a prompt transcript requires remembering where each CLI hid its data.
Provider lock-in vs. personal preference: Different developers on a team prefer different tools based on familiarity, token costs, or specific model capabilities:

“I personally use claude code more as compared to others and the reason for preference is just more familiarity with the product, and that is the reason I built wdx to work with multiple ACAs as everyone can have different preference but can still benefit from the wdx”

Rather than forcing everyone into one CLI ecosystem, wdx defines a clean abstraction called an ACA (AI Coding Agent). You choose the CLI per agent (--aca claude_code, --aca codex, --aca cursor, or --aca antigravity), and wdx adapts its runtime to fit.

wdx normalizes four distinct AI CLIs into one interface: identical worktree isolation, vt state detection, inbox message delivery, and unified usage tracking.

One protocol for all four

Under the hood, wdx does not rewrite or fork these tools. It runs the exact official CLI binaries you already have installed (claude, codex, cursor-agent, and agy) inside a managed pseudo-terminal (PTY) owned by a long-running background daemon.

This architecture gives every agent five core guarantees regardless of which provider runs it:

Terminal isolation: Agents run in independent holder processes. If you close your terminal emulator, disconnect SSH, or reboot your window manager, the agents continue working. Reconnecting via wdx tide or wdx agent attach instantly restores the screen.
Worktree isolation: Agents never collide on the filesystem. --worktree <name> automatically creates a dedicated git worktree in .worktrees/<name>, branching from HEAD. Claude Code and Codex can modify the same files simultaneously in separate checkouts without dirtying your main tree.
VT-based screen engine: Instead of relying on brittle terminal scrapers or vendor-specific telemetry APIs, wdx runs a headless virtual terminal (VT) for each agent. It parses screen output in real time to classify the agent’s state: working, idle, or waiting on human input.
Reliable inbox steering: When you send an agent instructions with wdx agent send, wdx queues the message in an inbox. It waits until the agent’s PTY is in raw mode and capable of accepting keystrokes before pasting the input, preventing dropped keys. For instant interruptions (--instant), wdx executes the CLI’s native steering shortcuts to gracefully background running tasks or stop output generation.
Clean docs and structured plans: Running multiple agents quickly produces coordination chaos if task definitions and architecture specs remain unmanaged. wdx stores project documents and dependency-driven task DAGs directly in its daemon database:

“wdx docs & plans are really helpful, even if you prefer to keep your shared/published docs in google docs/ notion/ confluence etc, i’d still suggest to utilise wdx for local docs that you generate while planning and brainstroming before publishing to wider audiance, as previously i used to have mess of local uncommitted md files generated temporarily, and then overtime would forget where each file sits and what was the purpose of it, but with wdx docs the git tree is clean, all the files are in one place and is easier to find. and apart from the local docs, the plans really help me get more hands free time, as once i have done a proper planning i can leave it to wdx to execute 1 step after the other”

Here is a recording showing all four AI coding agents running together on a demo repository—inspecting available ACAs, checking account usage across providers, viewing active agents in the CLI, and navigating them inside TIDE:

Claude Code, Codex, Cursor, and Antigravity running side by side under wdx: unified rate limits, status tracking, and TIDE fleet management.

Under the hood: Adapting to four different engines

Translating four distinct AI engines into a uniform protocol requires understanding the exact quirks, flags, and filesystem behaviors of each CLI.

Claude Code (`claude_code`)

Anthropic’s Claude Code CLI (claude) is the default ACA when installed. It exposes the richest terminal interface, which wdx adapts with surgical configuration:

Disabling mouse and alternate screen: By default, Claude Code hijacks the terminal’s alternate screen buffer and intercepts mouse clicks. wdx launches it with CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 and CLAUDE_CODE_DISABLE_MOUSE=1. This preserves full terminal scrollback and allows TIDE to handle mouse scrolling natively.
Interactive prompt parsing: Claude Code is currently the only ACA where wdx parses structured question dialogs from the screen buffer. When Claude asks for confirmation (yes/no) or presents multiple choices (decision), wdx extracts the prompt and options, surfacing them directly in wdx agent get and TIDE’s prompt overlay.
SendNow steering: To deliver high-priority instructions during a long generation, wdx uses Claude’s Ctrl+X Ctrl+S shortcut. A running command is shifted into the background rather than killed, and subsequent follow-up text is injected immediately.
Launch note injection: wdx injects its operational rules (AGENTS.md instructions on how to use wdx agent send, docs, and plans) via --append-system-prompt on every start and resume.

Codex (`codex`)

OpenAI’s Codex CLI (codex) operates through dated rollout files and custom turn notifications:

Developer instructions: Codex does not provide a direct CLI flag to append system prompts. Instead, wdx feeds its operational guidelines through Codex’s developer_instructions configuration, ensuring agents know how to coordinate with child agents and worktrees.
Session tracking via rollout logs: Codex writes conversational turns to ~/.codex/sessions/YYYY/MM/DD/rollout-*-<id>.jsonl. wdx monitors these files to track token usage, extract transcripts for wdx agent transcript, and restore deleted session files when resuming.
Turn tracking with notify: wdx hooks into Codex’s notify turn triggers to detect when execution steps begin and end, ensuring accurate state reporting in wdx agent list.

Cursor (`cursor`)

Cursor’s terminal agent (cursor-agent) relies on an internal SQLite database and project-level configuration:

Isolated configuration directory: To prevent concurrent agents from corrupting shared editor settings, wdx launches Cursor with a unique CURSOR_CONFIG_DIR=<backup>/cursor-config. Each agent receives its own sandboxed copy of cli-config.json while inheriting your global authentication and MCP server definitions.
Plugin session hooks: Cursor lacks a system prompt flag. wdx writes a lightweight plugin whose sessionStart hook injects wdx’s instructions as initial context whenever a new conversation begins.
Synthetic statusline footer: Cursor’s terminal UI does not render its standard footer when a custom statusLine command is active. wdx provides a statusline wrapper that computes token usage, renders a synthetic status bar matching Cursor’s visual style, and chains to your personal status script.
Safe workspace trust: wdx passes --trust on launch, saving trust preferences in ~/.cursor/projects/<path>/.workspace-trusted and preventing unexpected prompts from aborting automated tasks.

Antigravity (`antigravity`)

Google’s Antigravity CLI (agy) organizes its sessions around conversation databases and workspace rule files:

Workspace rules (AGENTS.md): Antigravity automatically detects and respects AGENTS.md files located in project workspaces. wdx injects its rules into a dedicated workspace folder, guiding the agent to use wdx doc and child agents rather than ad-hoc scripts.
SQLite VACUUM snapshots: Antigravity stores conversation state in SQLite WAL databases at ~/.gemini/antigravity-cli/conversations/<id>.db. To safely back up and resume conversations across worktrees without locking active writers, wdx takes read-only SQLite snapshots using VACUUM INTO.
Alt+M turn steering: When an instant message arrives while Antigravity is processing, wdx delivers Alt+M, queuing the new instructions to be handled at the start of the next execution step.

Depth over breadth

Building rock-solid adaptations for four completely different CLI engines requires deep protocol engineering. While the ecosystem is filled with emerging AI coding tools, wdx prioritizes reliability over superficial support:

“every ACA does things differently, you need to understand what each one does how they expose information and then parse it to general contract that wdx can understand. this is the only reason that I’m holding off for now to expand horizintally to more ACAs like Grok Build, Mistral Vibe, Qwen Code, Github Copilot CLI, OpenCode, Aider, Kilo CLI, Goose, crush etc. For now I’m focused on expanding the features that can help engineers use agents momre effectively and easily, and then jump on adding more ACAs support to wdx”

Side-by-side comparison

The following table summarizes how wdx bridges the technical differences between all four supported AI coding CLIs:

Feature	Claude Code	Codex	Cursor	Antigravity
CLI binary	`claude`	`codex`	`cursor-agent`	`agy`
Tested version	2.1.319	0.163.0	2026.11.05	1.5.2
Launch note source	`--append-system-prompt`	`developer_instructions`	Plugin `sessionStart` hook	Workspace `AGENTS.md`
Full permissions flag	`--permission-mode bypassPermissions`	`--dangerously-bypass-approvals-and-sandbox`	`--force --sandbox disabled --approve-mcps`	`--dangerously-skip-permissions`
Screen state parsing	Alternate screen off, raw VT parsing	Input box & statusline inspection	Box & synthetic footer inspection	Terminal VT buffer parsing
Question extraction	Structured `yes/no` & `decision`	Generic `waiting`	Generic `waiting`	Generic `waiting`
Turn steering	`Ctrl+X Ctrl+S` (SendNow)	Paste + Enter at next step	Enter x2 at next step	`Alt+M` at next step
Context tracking	Statusline JSON telemetry	Rollout log token count	Chat `store.db` inspection	Statusline JSON telemetry
Session storage	`~/.claude/projects/` JSONL	`~/.codex/sessions/` JSONL	`cursor-config/chats/` SQLite	`conversations/*.db` SQLite

Managing rate limits across providers

One of the largest hurdles when running multi-agent workflows is managing provider rate limits. An intensive refactoring or test generation loop can exhaust an hourly or daily quota window in minutes.

wdx usage aggregates rate limits across all four AI coding agent accounts into a single terminal report. It tracks rolling windows (5-hour session caps, weekly limits, and monthly pools), showing exact usage percentages, time until reset, and whether a model bucket is currently throttled:

wdx usage

antigravity Claude and GPT models  available
  WINDOW                           USED                          RESETS         AS OF
  Session (5 h)                    0%                            in 4 h 57 min  14:17
  Week                             0%                            Nov 14 04:12   14:17
antigravity Gemini models          available
  WINDOW                           USED                          RESETS         AS OF
  Session (5 h)                    0%                            in 4 h 45 min  14:17
  Week                             13%                           Nov 14 04:13   14:17
antigravity Gemini 4 Argon         limited, resets Nov 17 12:11
  WINDOW                           USED                          RESETS         AS OF
  Week                             100% limited                  Nov 17 12:11   14:17
claude_code                        available
  WINDOW                           USED                          RESETS         AS OF
  Session (5 h)                    6%                            in 42 min      13:48
  Week                             1%                            Nov 19 10:00   13:48
codex                              available
  WINDOW                           USED                          RESETS         AS OF
  Week                             16%                           now            14:27
cursor                             available
  WINDOW                           USED                          RESETS         AS OF
  Month                            3%                            Dec 1 19:31    18:08

This visibility unlocks flexible quota management across subscription tiers:

“when I’m running pro plans in every ACA there is more quick shuffling of ACAs so that the limit is evenly distributed, but when I have heavy work i upgrade claude to max plan which reduces the ACA shuffling, but this is just my preference, everyone can have there own way of working”

When running on Pro tiers, tasks can be distributed across providers—for example, assigning architectural reviews to Claude Code, test coverage sweeps to Codex, documentation generation to Cursor, and background audits to Antigravity. When Claude is upgraded to a Max plan, more tasks can run sequentially on Claude without risking unexpected rate limits.

One screen, any agent

Inside TIDE (wdx tide), all four AI coding agents appear side by side in the project navigator. You can monitor their progress, inspect live worktree diffs, answer questions, and land changes with a single keystroke:

wdx tide · shop-api

A multi-agent fleet in TIDE: reviewer (Claude Code), reviewer-tests and fix-auth (Codex), docs (Cursor), and checkout-emails (Antigravity) working simultaneously across isolated worktrees. Click, scroll and type: it is live, and runs nothing.

You don’t need to choose a single AI vendor or juggle four incompatible terminal setups. Run the tools you already know, distribute workloads across accounts, and let wdx handle the plumbing.

Install wdx:

Terminal

curl -fsSL https://raw.githubusercontent.com/srjn45/wdx/main/scripts/install.sh | sh

Verify which AI CLIs wdx detected on your system:
Terminal
```
wdx agent acas
```

Launch your fleet in dedicated worktrees and open TIDE:

Terminal

wdx agent create --name review --aca claude_code --worktree review-wt --prompt "..."
wdx agent create --name tests --aca codex --worktree tests-wt --prompt "..."
wdx tide

Read more about each CLI adapter in the AI CLIs Overview, Claude Code, Codex, Cursor, and Antigravity documentation. The project is open source on GitHub.

From one agent to five: what changed in my day

Thu, 12 Nov 2026 00:00:00 GMT

Before wdx, running AI agents meant a row of terminal tabs, and after a while I couldn’t remember which tab was doing what. The agents were fine. I was the one getting lost.

Here’s what changed when they moved onto one screen.

Left, terminal tabs lose context and stick to one AI CLI. Right, TIDE groups named agents into a tree, highlights questions in amber, and orchestrates multiple AI CLIs on one screen.

“Which tab was that again?”

Before wdx, running AI agents meant cycling through a dozen terminal tabs and split panes. The friction wasn’t just the keystrokes; it was the context switching. After an hour of coding, you’d glance across your tab bar and pause: Which tab was running the test suite? Which one was refactoring the parser? And is that third tab stuck waiting for my confirmation, or still thinking?

Because managing multiple terminals was so chaotic, I naturally stuck to a single AI CLI. Even when another tool had a better model for writing documentation or quick codebase exploration, the cognitive cost of juggling different terminal windows with different workflows wasn’t worth it.

Terminal tabs gave each agent an isolated shell, but they offered zero coordination. The moment you had more than two agents running, you spent more time managing tabs than reviewing code.

A name for every agent, and a parent for its children

In wdx, agents aren’t anonymous PTY sessions. You give each agent a name when you create it:

Terminal

wdx agent create --name notes-cli --prompt "Coordinate the notes app CLI refactoring"

When work gets split, wdx connects agents into a hierarchy. You can spawn child agents under a parent, each assigned to a focused subtask:

Terminal

wdx agent create --parent-name notes-cli --name delete --worktree notes-delete \
  --prompt "Add delete <n> to notes.py with a unittest"
wdx agent create --parent-name notes-cli --name search --worktree notes-search \
  --prompt "Add search <text> to notes.py with a unittest"
wdx agent create --parent-name notes-cli --name tests --worktree notes-tests --permissions ask \
  --prompt "Add test_notes.py with end-to-end tests"

In the agent list, children are clearly indented under their parent with └. You are never left wondering why an agent exists: you see immediately that delete, search and tests are three child agents working together under notes-cli.

A parent row folds with ← and unfolds with →. When folded, it keeps your view tidy while still showing N waiting if any child beneath it needs attention.

Everything in front of my eyes

TIDE, wdx’s Terminal IDE, puts everything on a single screen: the project pane on the left, the active agent live on the right, and project terminals below.

wdx tide · shop-api

Every agent at a glance: row marks show activity, children are indented, and questions turn amber. Click, scroll and type: it is live, and runs nothing.

Visual indicators make tracking what’s happening second nature:

Row marks: ● for running, ? for waiting on you, ○ for exited, ✕ for failed.
Amber alerts: When an agent needs input—like a permission confirmation or a tool prompt—its row turns amber and displays what it wants: yes/no or decision.
Answering in place: Hit Enter or o on an amber row to switch to the agent’s tab, answer its question, and watch it immediately transition back to ● working.

wdx tide · shop-api

Answer an agent's question directly in its tab without leaving TIDE. Click, scroll and type: it is live, and runs nothing.

When paired with plans, tracking progress becomes effortless. As I wrote in I built wdx with wdx, wdx carries plan tasks forward one after another, letting you monitor an entire pipeline from a single vantage point.

Here is what running five agents looks like in practice on a toy project: notes-cli with its three children (delete, search, tests) in git worktrees, plus a Codex agent docs. When tests raises a permission question, it is answered directly in its tab, and C-q S opens the stats view:

Five agents on one screen: a parent with three children in worktrees, a Codex agent, answering a question in place, and checking limits in the stats tab.

More than one AI CLI, the same way

Before wdx, running multiple AI CLIs simultaneously was impractical. Each tool had its own conventions, its own process model, and its own way of monopolizing your terminal.

With wdx, you can use multiple AI CLIs—Claude Code, Codex, Cursor, Antigravity—side by side on the same repository. The orchestration is handled entirely by wdx, so your interaction as a user is identical regardless of the underlying ACA:

Terminal

wdx agent create --name notes-cli --aca claude_code --prompt "Refactor notes.py"
wdx agent create --name docs --aca codex --prompt "Document the CLI in README.md"

Each agent works in a git worktree of its own, so they never overwrite each other’s edits or step on git status. Run Claude Code and Codex side by side walks through how worktrees prevent conflicts and land cleanly on main.

Agents that survive a reboot

One of the most frustrating aspects of running long-lived agents in standard terminal tabs is computer restarts. Close your laptop, reboot for an OS update, or crash your terminal emulator, and your active sessions vanish into the void.

wdx runs as a system service (via systemd on Linux or launchd on macOS) that starts automatically on boot or login. When the daemon starts again after a reboot, your agents aren’t lost: they are listed with state lost:

Terminal

$ wdx agent list
NAME       STATE  ACTIVITY  MODEL  CONTEXT  ACA          DIR          ID
notes-cli  lost                             claude_code  /path/notes  agent-facac2a3

You don’t need to hunt for obscure session IDs. You simply start the agent by its name:

Terminal

wdx agent start --name notes-cli

In TIDE, it’s a single keystroke: press g on the agent’s row. The agent respawns with its entire conversation history and context intact, exactly where it left off.

If you ever want a fresh session while keeping the agent’s identity, wdx agent restart (or R in TIDE) starts an empty session that reads wdx agent transcript --brief.

Agents survive reboots: stopping the daemon marks agents as lost; wdx agent start brings them back in the same session.

The numbers

Moving from one agent in loose terminal tabs to five agents in TIDE transformed my daily output. Here is the commit history from wdx’s own repository around the transition:

Period	Days	Commits	Commits / day
26–28 Oct, one agent	3 days	57 commits	~19/day
29 Oct–11 Nov, wdx and TIDE	14 days	654 commits	~47/day

On the busiest single day (8 November), the team landed 89 commits.

A fair caveat: the first three days were also the start of a brand new project, where laying foundational architecture naturally takes more deliberate deliberation than adding subsequent features. But once attach and TIDE landed on 29 October, the ability to coordinate multiple agents in parallel without losing mental context more than doubled daily throughput.

Choosing where the next task goes

When you run five agents across different providers, managing rate limits and context budgets is critical.

Pressing C-q S in TIDE (or running wdx usage from the CLI) opens the stats tab:

┬─[● notes-cli(-)]─[stats(-)]────────────────────────────[⤢]─┐

   claude_code:                available
     Session (5 h):            1% ▰▱▱▱▱▱▱▱▱▱   resets in 3 h 48 min
     Week:                     98% ▰▰▰▰▰▰▰▰▰▰  resets in 8 h 28 min
     as of:                    01:28

   codex:                      available
     Week:                     16% ▰▰▱▱▱▱▱▱▱▱   resets in 24 h
     as of:                    14:27

   cursor:                     available
     Month:                    3% ▰▱▱▱▱▱▱▱▱▱   resets Dec 1
     as of:                    18:08

   antigravity Gemini 4 Argon: limited, resets Nov 17 12:11
     Week:                     100% limited

Because you can see that Claude Code’s weekly limit is at 98%, you know it is about to exhaust. Instead of hitting an unexpected quota brick wall midway through a feature, you spawn the next task with Codex or Antigravity.

Context sizes are also visible right on each row in the agent list (e.g. 45k, 180k). The context number stays green during early turns, turns yellow once it passes context.threshold.warning, and turns red at context.threshold.critical. That visual feedback makes timely context compaction second nature.

Importantly, wdx only displays this information: it never pauses, cancels, or switches models behind your back. You remain the conductor.

What’s still missing

While managing five agents on one screen is a massive leap forward from disjointed terminal tabs, there is still plenty to achieve:

Feature parity across all ACAs: TIDE’s ability to read specific prompt questions—surfacing them as yes/no or decision in amber—currently works best with Claude Code. Other AI CLIs still report generic waiting status. Bringing deep question parsing to Codex, Cursor, and Antigravity is an active focus.
Autonomous handling: Expanding the orchestration layer so child agents can hand off deliverables, trigger follow-up checks, and coordinate interdependent tasks with less manual steering.

Try it

Install wdx and its system service:

curl -fsSL https://srjn45.github.io/wdx/install.sh | sh

Open your project:
```
cd my-project
wdx project open
```

Create a lead agent and a child:

wdx agent create --name lead --prompt "Review pending pull requests"
wdx agent create --parent-name lead --name feature --worktree feature-branch \
  --prompt "Implement the search endpoint"

Open TIDE:
```
wdx tide
```

Agents in TIDE

Learn how to navigate agent rows, inspect questions, and fold parent trees in Agents in TIDE.

Child agents guide

See how parent agents delegate subtasks to children in Child agents.

Stats in TIDE

Track account usage windows and model buckets across all AI CLIs in Stats in TIDE.

GitHub

Explore the source, report issues, and star the project on GitHub.

Plans: split a feature into tasks and let agents run them

Thu, 12 Nov 2026 00:00:00 GMT

Asking an AI coding agent to build a multi-file feature in one giant prompt usually ends the same way: it loses track of constraints, hallucinates file state, or exhausts its context window halfway through.

The fix is to break the feature into a directed acyclic graph (DAG) of small, focused tasks—and let an orchestrator run each task’s agent in parallel as soon as its dependencies are ready.

How wdx executes a plan: tasks run in parallel slots as dependencies clear, receive synthesized context from finished tasks, and rebase atomically onto the plan branch.

Why big features break single prompts

When an AI agent works inside a single massive session across dozens of files, three things inevitably go wrong:

Context degradation: As conversation history swells past 150k tokens, attention drifts. Constraints stated in turn 2 are forgotten by turn 20.
File drift and hallucinations: The agent assumes a file looks the way it remembered eight tool calls ago, creating subtle regressions and mismatched interfaces.
Runaway blast radius: When an agent tries to edit the database schema, HTTP handlers, CLI commands, and test suites in one go, a single mistake cascades through every file.

In traditional software development, we size tasks by developer hours or story points. When working with AI coding agents, that scale flips entirely. As I’ve found while building wdx with wdx:

“Each task spawns in its own worker agent. What I usually prefer is it should be completed within ~300k context size. Sometimes there are longer running workers as well, but on average I prefer each individual task to be done in a considerable amount of context. As the main purpose of wdx is to use agents, I’m no longer looking at tasks in terms of usual difficulty level; instead, I now changed my scale to the context size needed for a task to complete.”

Sizing tasks by context budget (~300k tokens) keeps every agent sharp, fast, and strictly bounded.

Brainstorm first, let an agent write the plan

I never write plan YAML files by hand from scratch. Instead, I let an agent draft the plan, and I review it before anything executes:

“I’ve never written a plan by myself; I always let an agent write the plan. What I do is review the plan and make any modification before starting it. My usual flow is to brainstorm an idea with the AI agent, let it document the process using the wdx docs, and once I’m satisfied with the approach, the architectural design, etc., I ask it to make a wdx plan for it. Then I review the plan just to ensure that all the steps make sense, as the result of each plan is intended to be landed to main, making sure that each plan in itself is deployable.”

Here is the three-step flow:

Brainstorm in a doc: An agent helps work out the technical design in a project doc (wdx doc create --name SSO).
Generate the plan YAML: Once approved, the agent converts the design into a plan definition and pipes it directly to wdx plan create --name sso --path -.
Review before running: You inspect the plan with wdx plan status --name sso or open it in TIDE. You verify that every task has a clear boundary, sensible dependencies, and produces a deployable commit.

Anatomy of a plan: the YAML

A plan is pure YAML, validated by wdx whenever it is saved:

release.yaml

goal: Get the app ready for its first open-source contributors.
constraints:
  - Run python3 -m unittest before each commit.
  - Keep each new documentation file concise.
tasks:
  - id: contributing
    aca: claude_code
    model: sonnet
    prompt: |
      Create CONTRIBUTING.md explaining how to run the test suite,
      and commit it on this branch.
  - id: license
    aca: claude_code
    model: sonnet
    after: [contributing]
    prompt: |
      Create LICENSE with MIT license text, and commit it on this branch.

Every plan definition contains:

goal (required): High-level purpose of the feature. Every worker agent is told this goal so it understands what its task contributes to.
constraints (optional): A list of non-negotiable rules (e.g. test requirements, linters, style guidelines) passed to every task.
tasks: The DAG nodes. Each task specifies:
- id: Letters, numbers, and hyphens (up to 50 characters).
- aca and model: Which installed AI CLI and model execute the task (e.g. claude_code with sonnet, codex with gpt-5, or antigravity with gemini-4-argon-high).
- after: The list of tasks that must complete and land before this task starts. Tasks with no after start immediately.
- prompt: The task-specific instructions for the agent.

Terminal

wdx plan create --name first-release --path release.yaml

Every plan is checked on save: syntax errors, missing fields, unknown models, duplicate task IDs, and circular dependency cycles are caught immediately with line-numbered diagnostics (invalid_plan).

Running the plan: slots, worktrees, and context handoff

When you run a plan, wdx takes over as orchestrator:

Terminal

wdx plan run --name first-release

Behind the scenes:

Dedicated branch: wdx creates branch plan/first-release from your project’s default branch.
Worktree slots: Instead of creating a throwaway worktree per task, wdx uses reusable slots: .worktrees/<plan>-1, .worktrees/<plan>-2, up to plan.parallel (3 by default, or overridden via --parallel).
Prompt synthesis: When a task agent starts in its slot, wdx synthesizes a complete, focused initial prompt:
- The plan’s overall goal
- All shared constraints
- The summaries of completed tasks listed in after
- The task’s specific prompt
- Instructions on how to commit and report completion

Synthesized Agent Prompt

You are doing task license of the plan first-release, run by wdx.
Goal: Get the app ready for its first open-source contributors.
Constraints:
- Run python3 -m unittest before each commit.
- Keep each new documentation file concise.

Done before you, which this task waits for:
- contributing: Created CONTRIBUTING.md with test suite instructions (commit 8a1b2c3).

Your task:
Create LICENSE with MIT license text, and commit it on this branch.

When it is done, commit your work on this branch, then run:
    wdx plan task done --agent-id $WDX_AGENT_ID --summary "<what you did, in a few lines>"

This context handoff is clean: the license agent never inherits hundreds of thousands of tokens of old shell output from contributing. It receives only the distilled summary and commit hash it needs, starting with a clean context window.

Here is a plan running on our toy notes repository:

Running a plan on the demo repository: tasks execute in slots, hand off summaries, and land on plan/release.

Watching the graph unfold: CLI and TIDE

While a plan runs, you can follow its progress from the CLI:

$ wdx plan status --name first-release
first-release: running, 1/2 tasks done, on plan/first-release
  goal        Get the app ready for its first open-source contributors.
  constraint  Run python3 -m unittest before each commit.
TASK          STATE                     ACA          MODEL   AFTER         AGENT                       SLOT
contributing  done                                   claude_code  sonnet
license       running                   claude_code  sonnet  contributing  first-release-license       first-release-1

You can inspect individual tasks with wdx plan task get:

$ wdx plan task get --plan first-release --task contributing
contributing of first-release: done
  summary  Created CONTRIBUTING.md with instructions to run unittests (a4b1c2d).
  agent    first-release-contributing
  slot     first-release-1

In TIDE, press Enter on a plan in the left sidebar to open its visual dashboard. TIDE renders the DAG as a live commit-graph rail (just like git log --graph), showing status marks, dependency indicators (▲ needs, ▼ unblocks), and task details:

wdx tide · shop-api

TIDE's visual plan dashboard: DAG rail on the left, dependencies marked with ▲ and ▼, and live task status. Click, scroll and type: it is live, and runs nothing.

Landing tasks: atomic rebases and landing checks

When a worker agent finishes its task, it runs:

Terminal

wdx plan task done --agent-id $WDX_AGENT_ID --summary "Implemented user authentication routes"

wdx handles the landing with strict verification:

Commit check: wdx checks the slot’s git status. If there are uncommitted changes or unstaged edits, it refuses with not_committed. The agent cannot complete until everything is committed.
Project landing check: If your project configured a landing check (wdx project landing --check "make test"), wdx executes that check in a dedicated background terminal named land-<slot>.
Atomic rebase: Once the check passes, wdx rebases the task’s commits onto plan/<name> using git rebase --onto.
Agent cleanup & unblocking: wdx terminates the task’s agent, frees the slot, and unblocks any downstream tasks waiting on this task’s completion.

Because landing rebases onto plan/<name>, your plan’s branch stays clean and linear—no messy merge commits.

When tasks fail: resolving conflicts with retries

In autonomous software development, failures happen: an agent might write code that fails the test suite, or two parallel tasks might touch conflicting lines in the same file.

When a landing check fails or git hits a rebase conflict:

$ wdx plan status --name first-release
first-release: running, 1/2 tasks done, 1 failed, on plan/first-release
  goal        Get the app ready for its first open-source contributors.
TASK          STATE                                               ACA          MODEL   AFTER         AGENT                  SLOT
contributing  done                                                claude_code  sonnet
license       land failed: check (terminal land-first-release-1)  claude_code  sonnet  contributing  first-release-license  first-release-1

wdx does not crash or abort the rest of the plan. Independent tasks keep running. The failed task pauses and reports diagnostics:

$ wdx plan task get --plan first-release --task license
license of first-release: land failed: check (terminal land-first-release-1)
  after    contributing
  agent    first-release-license
  worktree /home/you/notes/.worktrees/first-release-1
  check    its output in the terminal land-first-release-1

As the author notes:

“Usually a task can fail on conflicts, which can be easily resolved by retrying the task. It just needs a manual nudge that can be later on handled by wdx automatically, but for now I prefer to keep things manual.”

You have full control over how to resolve it:

wdx plan task retry --plan <name> --task <id>: Resumes the agent in its existing session, passing a note that explains the failure (the check failure output or conflicting files).
wdx plan task retry --plan <name> --task <id> --fresh: Starts a brand new agent in the slot, informed of the earlier commits.
wdx plan task land --plan <name> --task <id>: If you resolved the conflict or fixed the test manually inside .worktrees/<plan>-<n>, run this to re-run the check and rebase onto the plan branch.
wdx plan task skip --plan <name> --task <id>: Skips the task, allowing downstream tasks to proceed.

Resolving a failed task: inspect failure output in land-slot terminal, retry with a fresh nudge, and land cleanly.

From single plans to plans of plans

Plans scale from small tactical fixes to entire product architectures:

“I have executed both plans and plan of plans. It can be as simple as marking an agent limited when the ACA ran out of usage quota, or it can be as complex as building the complete hub feature with plan of plans.”

In wdx’s own history:

agent-limited: A single 5-task plan (buckets → limited → tide → checked → finish) that added quota limit tracking across all four AI CLIs.
hub: A plan of plans comprising 10 sequential child plans (hub-sqlite → hub-settings → hub-clikit → hub-skeleton → hub-accounts → hub-login → hub-docs-push → hub-tunnel → hub-node-commands → hub-remote-tide). Each child plan ran its own DAG of worker agents, tested its domain, and landed to main before the next plan began.

Plan of Plans (hub.yaml)
Single Plan (agent-limited.yaml)

hub.yaml

goal: |
  The wdx-hub MVP: the ten hub plans in order, each landing in main
  before the next starts.
plans:
  - id: hub-sqlite
  - id: hub-settings
    after: [hub-sqlite]
  - id: hub-clikit
    after: [hub-settings]
  - id: hub-skeleton
    after: [hub-clikit]
  - id: hub-accounts
    after: [hub-skeleton]
  - id: hub-login
    after: [hub-accounts]
  - id: hub-docs-push
    after: [hub-login]
  - id: hub-tunnel
    after: [hub-docs-push]
  - id: hub-node-commands
    after: [hub-tunnel]
  - id: hub-remote-tide
    after: [hub-node-commands]

agent-limited.yaml

goal: >-
  An agent is marked limited while a bucket its model draws on is limited,
  and not while another bucket of its ACA is.
constraints:
  - Tests never touch the network and never start a real ACA.
  - Work only in the worktree the plan gave you.
tasks:
  - id: buckets
    aca: claude_code
    model: opus
    prompt: Give aca.AiCodingAgent a ModelBuckets method...
  - id: limited
    aca: claude_code
    model: opus
    after: [buckets]
    prompt: Derive an agent's limit in the daemon...
  - id: tide
    aca: claude_code
    model: opus
    after: [limited]
    prompt: Show the limit in tide...
  - id: checked
    aca: claude_code
    model: opus
    after: [tide]
    prompt: Check the built daemon by hand...
  - id: finish
    aca: claude_code
    model: opus
    after: [checked]
    prompt: Update docs and the website...

Stacked pull requests

When you collaborate with human reviewers on GitHub, waiting for a PR review before writing the next piece can stall your team.

wdx supports stacked PRs directly in plan definitions:

pr: true
stacked: true

With pr: true, wdx automatically creates a pull request via gh when a plan completes. With stacked: true, a downstream child plan doesn’t wait for the upstream PR to be merged—it immediately branches from the upstream plan’s branch (plan/feature-b off plan/feature-a) and opens a stacked PR targeting plan/feature-a.

When the upstream PR is merged into main, running:

Terminal

wdx worktree rebase --name feature-b-1

detects the merge via GitHub’s API, rebases the commits onto main using git rebase --onto, and updates the PR target on GitHub automatically.

Try it

Install wdx:

curl -fsSL https://raw.githubusercontent.com/srjn45/wdx/main/scripts/install.sh | sh

Open your repository:
```
cd my-project
wdx project open
```

Brainstorm a plan with an agent:

wdx agent create --name planner --prompt "Read our architecture docs and write a wdx plan in plan.yaml for adding user export"

Inspect and run the plan:

wdx plan create --name export --path plan.yaml
wdx plan run --name export
wdx tide

Plans Guide

Read the complete guide to creating and managing plans in Plans.

Running Plans

Learn about slot limits, pause/resume, and landing checks in Running plans.

Docs & Plans in TIDE

Explore navigating the DAG rail, inspecting tasks, and handling retries in Docs and plans in TIDE.

GitHub Repository

Explore the codebase, read our development plans, and star the project on GitHub.

I built wdx with wdx: a team of AI agents wrote most of its code

Wed, 11 Nov 2026 00:00:00 GMT

In 16 days wdx went from its first commit to v0.5.0: 703 commits and about 185,000 lines of Go, generated code left out. All of that code was written by AI agents, run by wdx itself. I did the planning and the design, with in-depth analysis and brainstorming, and every approval.

This is how that works, and why it is not magic. You keep using your favourite AI CLI the way you did before. What wdx adds is an orchestration layer: one screen to run and keep track of many agents, and plans that carry pre-planned work on, step after step, until something needs a person.

Go lines in the tree at each release, generated code left out, by day since the first commit on 26 October 2026.

The next-generation warden

wdx is the next-generation warden, an agent tool I had built before; the logo writes it wdˣ, with the x as an exponent. The x has a second meaning. wdx dropped tmux and built its own detached terminals, which keep running when you close the window and let you attach again as tmux does. The screen of each one is kept by x/vt, which I forked to add fixes, patches and features of our own on top.

So there were no big surprises. I had built something like it, and over time I had learned what is actually needed and how to build it. warden’s story gets a post of its own later in this series.

One agent, slowly, on purpose

Until wdx had attach, I built it with a single Claude Code agent. Only one, so I would not lose focus or get confused by switching contexts. The early development was slow, but very well thought out.

Once agents could be attached, I started using that a little. Once attach was complete, I moved to TIDE, the Terminal IDE, because that is what gives the full benefit of wdx: many agents, all visible on one screen and easy to keep track of. TIDE is where I work now, and I never leave it.

Building wdx with wdx also gave me continuous feedback: every feature was tested in real work, and the pain points and the improvements showed up in my own day.

Per release: the commits since the release before, and the Go lines they added, generated code left out. Each chart has its own scale.

Release	Date	Commits	Go lines (of which tests)	Go lines added
v0.1.0	28 Oct	32	11,064 (4,781)	11,012
v0.2.0	1 Nov	185	50,104 (23,032)	41,208
v0.3.0	3 Nov	76	85,421 (38,232)	36,124
v0.4.0	7 Nov	190	129,069 (59,095)	45,919
v0.5.0	11 Nov	220	185,168 (86,398)	63,019

Design before code

The first rule of the workflow in wdx’s AGENTS.md, the file every agent working on it reads, is: Never start coding until the human explicitly says so. Design comes first, worked out with an agent: the structure, the tables, the commands, the names, the edge cases.

That design is a wdx doc: kept in wdx rather than in the repository, with a revision per change and a status, wip, then review, then approved. Every agent reads the same doc the moment it changes, whatever branch it is on. wdx itself has 77 of them today: 34 approved, 12 in review and 31 still wip.

wdx tide · shop-api

A doc in TIDE: designs live in wdx, with a status that says whether they are agreed on. Click, scroll and type: it is live, and runs nothing.

From approved design to a plan that runs for hours

Once a design is final, I ask an agent to turn it into a plan: the work split into tasks, each with the tasks it waits for (after:). Then I let the plan run, and check on it now and then. Sometimes a plan runs for hours without needing me.

Running a plan makes a branch for it, plan/<name>, and starts an agent for every task that is ready, each in a worktree of its own, up to plan.parallel at once (3 by default). When a task is done, wdx lands its work on the plan’s branch, after the project’s landing check, and starts what waited for it. A task that fails waits for me; the rest goes on. When every task is done, one worktree is left on the plan’s branch, and landing it is my call.

Teal is yours to do: the design, the approval and the landing. The rest is the agents' and wdx's, and a task that fails waits for you.

Here is the same thing on a toy project, with real Claude Code agents: three tasks, two at once and one after both.

A plan of three tasks on a toy repository: wdx runs each task’s agent once what it waits for is done.

wdx tide · shop-api

A plan in TIDE, drawn the way git log --graph draws commits. Click, scroll and type: it is live, and runs nothing.

wdx has 51 plans so far: 31 done, 18 drafts and 2 running as I write this. This blog series is one too, a plan of plans called blogs: each post is a plan, and this one was written by an agent wdx started, from an outline I approved.

Five or six agents, sometimes fifteen

On a normal day I run five or six agents at once. At most I have had twelve to fifteen, some of them started and managed by plans.

Agents also split their own work. Every agent wdx starts gets a launch note telling it that it runs under wdx and to read wdx help agents, so when it wants a subagent it makes a child agent through wdx instead, in a worktree of its own. The children show up in TIDE under their parent, where I can watch, answer or steer them.

A Claude Code agent splits a change between two child agents, each in a worktree of its own, on a toy repository.

One CLI first, the others after

Claude Code is the AI CLI I used most. I used the others now and then, for reviews and documentation. That is why each new feature reaches Claude Code first and the other AI CLIs later.

What still needs a person

Yours

Every approval, every review, and when to land the code.

The agents'

Writing the code, in worktrees, and carrying a plan on until something needs you.

All the approvals, the reviews and the decision of when to land are still human. More autonomy will come, but it has to be designed carefully: taking away only the repetitive, no-brainer work, and still leaving the complex reasoning and the decisions to a person.

Try it

wdx runs on Linux and macOS. Keep the AI CLI you already use; wdx runs it.

Install wdx and open a project:

Terminal

curl -fsSL https://raw.githubusercontent.com/srjn45/wdx/main/scripts/install.sh | sh
wdx project open --local ~/code/api

Start an agent in a worktree of its own, and open TIDE:
Terminal
```
wdx agent create --name fix --worktree fix
wdx tide
```
When the work is bigger than one agent, write a plan and run it.

The code, the issues and every release are on GitHub.

Run Claude Code and Codex side by side on one repo, without stepping on each other

Wed, 11 Nov 2026 00:00:00 GMT

You want Claude Code on the feature and Codex on the tests, both at once. Start them in the same checkout and within minutes one is editing a file the other just changed, git status belongs to neither, and you can’t tell whose half-finished work you’re about to commit.

The fix is old git: one worktree per agent. wdx makes it one flag.

Working with several AI CLIs at once is seamless for me: there are no overwrites, because every agent works in its own worktree, and wdx takes care of orchestrating the agents. They can even talk to each other through wdx’s messages.

This post walks through it on a toy repository, notes, a tiny command-line notebook in Python: Claude Code adds a delete command while Codex adds search, each in a checkout and on a branch of its own, in the same clone. Then both land on main, one after the other.

Why one checkout breaks with two agents

A checkout is one working tree and one index. Two agents in it share both: every file either one saves is the file the other reads next, and a commit takes whatever is staged, whoever staged it.

A git worktree is a second checkout of the same repository, in a folder of its own, on a branch of its own. The commits are shared, the files are not. The catch has always been the bookkeeping: making them, naming them, remembering which agent is in which, and cleaning them up. That part is what wdx does.

Left, two agents share one working tree and one index. Right, each has a checkout and a branch of its own in the same clone, and lands in turn.

Start each AI CLI in a worktree of its own

--worktree on wdx agent create starts the agent in a worktree of that name, and --aca picks the AI CLI:

Terminal

wdx agent create --name notes-delete --worktree notes-delete --aca claude_code \
  --prompt "Add a 'delete <n>' command to notes.py that removes note n, with a unittest in a new file test_delete.py, then commit it"
wdx agent create --name notes-search --worktree notes-search --aca codex \
  --prompt "Add a 'search <text>' command to notes.py that lists the notes containing the text, with a unittest in a new file test_search.py, then commit it"

A name that matches no worktree creates one in .worktrees/<name> at the project’s root, on a new branch of that name from the HEAD of where the agent would otherwise start. main always means the clone itself. wdx keeps .worktrees out of git status, and removing an agent leaves its worktree alone, since it may hold work not landed yet.

Both prompts touch the same lines of notes.py on purpose: each command needs its own branch in main() and its own word in the usage line. Hold on to that for the landing.

Claude Code and Codex start on the toy repository, each in a worktree of its own, until both have committed.

Watch both from one screen

wdx agent list says what each one is doing, which AI CLI it runs, its model and how full its context is:

wdx agent list

NAME          STATE    ACTIVITY  MODEL      CONTEXT  ACA          DIR
notes-delete  running  idle      Opus 5.5   43k      claude_code  /tmp/wdx-demo.idWtDE/notes/.worktrees/notes-delete
notes-search  running  idle      GPT-6-Sol  18k      codex        /tmp/wdx-demo.idWtDE/notes/.worktrees/notes-search

In TIDE, wdx tide, the same agents are rows of the left pane, and the Worktrees section under them says how far each worktree is ahead of main (↑1), the lines it adds and removes, and what is not committed yet. Enter on an agent shows its screen on the right.

Let them talk to each other

An agent is reached with wdx agent send, from your shell or from another agent:

Terminal

wdx agent send --name notes-search --prompt "notes-delete changes main() in notes.py too: keep your change there small"

wdx keeps the message until it has been typed into the agent’s input box, so one sent while the agent is busy or still loading is not lost, and wdx message list shows those still waiting.

Review each one’s work

wdx worktree list gives every worktree with how far it is ahead (AHEAD) and how many files are not committed (CHANGED). wdx worktree diff --name notes-delete prints what it committed since it left main, as its pull request would show it, and --uncommitted what it has not committed yet. Both only read, so they run beside whatever git an agent is running.

In TIDE, Enter on a worktree opens its tab, the same diff. There v marks a file as looked at, C asks the agent there to commit what is left, and c writes a comment on a line, which s sends to an agent as one review. Here it is in the site’s demo, which you can click through:

wdx tide · shop-api

A worktree's tab: [ ] moves between changes, { } between files, L lands it. Click, scroll and type: it is live, and runs nothing.

Land them one after the other

A project says once how it lands. Without that, landing fails with land_not_configured. For notes the check is its tests:

Terminal

wdx project landing --name notes --check "python3 -m unittest"
wdx worktree land --name notes-delete

wdx worktree land rebases the worktree if main has moved on since it branched, runs the check in a terminal named land-<worktree>, which stays open if the check fails, and then fast-forwards main to the commit it checked. No merge commit. On any failure, main stays where it was. It refuses a worktree with files not committed (not_committed) or with an agent still working in it (agent_working).

If you’d rather review on GitHub, --method pr runs the check, pushes the branch and opens a pull request with gh instead.

When both touched the same lines

“Without stepping on each other” means no agent overwrites another’s work while they work. Landing is another matter: both changed main() in notes.py, and once notes-delete has landed, main has moved on under notes-search.

So landing notes-search rebases it onto the new main, and git stops on the conflict. wdx undoes the rebase at once, so the worktree and main are just as they were, and says what happened:

Terminal

$ wdx worktree land --name notes-search
wdx: rebase onto main stopped on a conflict in notes.py  [rebase_failed]
  hint: nothing changed; ask an agent to rebase with wdx agent send, then land again

In TIDE, the worktree’s row says conflict, and a landing that fails while TIDE is open says notes-search: rebase stopped on a conflict in 1 file, undone: L asks an agent. L in the worktree’s tab then opens a box to an agent, the one in that worktree first, with the request already written: Rebase notes-search onto main in <its path>, resolving the conflicts. Enter sends it. Codex rebases and keeps both commands, and you can watch the conflict get resolved in the tab. The row still says conflict until the next landing: L again runs the check, lands it, and TIDE offers to remove the worktree.

The first worktree lands; the second stops on a conflict, Codex rebases it from TIDE, and it lands on a straight main.

From the CLI, wdx worktree rebase --name notes-search runs the rebase on its own and reports the same conflict, but it sends nothing to any agent: that is what wdx agent send is for, then land again.

Clean up

wdx worktree remove --name notes-delete removes a worktree only when nothing is ahead of main and nothing is uncommitted, so no commit can be lost. It deletes the branch too when git says it is merged, and tells any agent still running there where to go on. In TIDE, C-q x on a worktree that landed does the same, and landing offers it straight away.

Try it

wdx runs on Linux and macOS, with the AI CLIs you already have installed.

Install wdx and open a project:

Terminal

curl -fsSL https://raw.githubusercontent.com/srjn45/wdx/main/scripts/install.sh | sh
wdx project open --local ~/code/api

Start two AI CLIs, each in a worktree of its own:

Terminal

wdx agent create --name feature --worktree feature --aca claude_code --prompt "..."
wdx agent create --name tests --worktree tests --aca codex --prompt "..."

Watch them, review and land each one:
Terminal
```
wdx tide
```

More in Worktrees and landing, Worktrees in TIDE, and the pages on Claude Code and Codex. The code is on GitHub.

Introducing wdx

Sun, 08 Nov 2026 00:00:00 GMT

Running one AI coding agent is easy: open a terminal and start it. Running four at once is where it falls apart. One is waiting on a yes/no question in a tab you closed an hour ago. Two are editing the same files. The laptop went to sleep and took a session with it. And at the end of the day you have to piece together what each one actually changed.

wdx is what I built to run them like a team rather than a pile of terminals.

Agents that outlive your terminal

wdx is one binary with three faces: a daemon, a CLI and TIDE, its Terminal IDE.

The daemon runs every agent and terminal in a pseudo-terminal of its own, owned by a small holder process. Close TIDE, close the terminal, restart or even update the daemon, and the agents keep working. Open TIDE again and everything is where you left it.

wdx runs the AI CLIs you already use, Claude Code, Codex, Cursor and Antigravity, with the same features on each. Its own features come first: whichever CLI an agent runs, it is created, watched, answered and resumed the same way.

Knowing who needs you

The hardest part of running agents in parallel is knowing which one is stuck. wdx reads each agent’s screen and tells working, waiting and idle apart, for every CLI it supports. When an agent asks a question, its row in TIDE turns amber and shows what kind of question it is. You can answer from TIDE without switching to it. Each row also shows how much of its context the agent has used.

A worktree per agent

An agent given a worktree works on a branch of its own, so two agents never edit the same checkout:

wdx agent create --name fix-auth --worktree fix-auth --aca codex

TIDE lists every worktree with what it has committed and what it has not, and shows the diff file by file. When it looks right, wdx worktree land puts it on main without a merge commit, or opens a PR.

Plans: a feature split into tasks

For a bigger change, a plan splits the work into tasks that depend on each other. wdx starts an agent for each task that is ready, each in a worktree of the plan’s, and lands every finished task on the plan’s branch. TIDE draws the plan the way git log --graph draws commits. A task that fails waits for you to retry it, land it or skip it.

The same features for scripts and agents

Everything TIDE can do, the CLI can do too, and every command takes --json. It then prints one JSON object with a stable error code and never prompts. That is how agents use wdx themselves: wdx help agents teaches an agent to make child agents, worktrees, docs and plans through wdx, so you see all of their work in TIDE as well.

Designs live in wdx as docs with revisions and a status, from wip to approved, so people and agents read the same thing.

Try it

wdx runs on Linux and macOS:

curl -fsSL https://raw.githubusercontent.com/srjn45/wdx/main/scripts/install.sh | sh
wdx project open --local ~/code/api
wdx agent create --name fix --worktree fix
wdx tide

Or try TIDE right now in your browser on the home page. It is a replica that runs nothing, but it has the same layout, keys and screens.

Update — 11 November 2026: the optional self-hosted hub is now available for remote access and document uploads. See Using a hub and Running a hub. The hub is operated by you or your organisation; the project does not offer a public hosted hub. The explicit --url requirement is planned for v0.6.0; v0.5.0 users should also supply their self-hosted hub’s URL.

wdx | Blog

Four ways running several AI agents goes wrong, and how wdx fixes each

Failure 1: The Disappearing Session (Lost Terminals)

The problem

How wdx fixes it: Daemon-Managed PTY Holders

Failure 2: The Stepped-On Source Tree (Clashing Edits)

The problem

How wdx fixes it: Isolated Git Worktrees

Failure 3: The Silent Stoppage (Unanswered Prompts)

The problem

How wdx fixes it: Real-Time VT Screen Parsing & Amber TIDE Badges

Failure 4: The Blind Merge (Mystery Diffs)

The problem

How wdx fixes it: In-Tab Diff Review & Guarded Landing

Comparison Matrix: Plain Terminals vs. wdx

Try It

A tour of TIDE, the terminal IDE for AI agents

The problem with terminal tabs

The three-pane layout

Key interception philosophy

Mouse support and persistence

The full agent lifecycle

Answering waiting agents

Browsing code & in-tab edits

Living docs & ASCII plan graphs

Living architecture specs

ASCII plan graphs

Contextual menu & in-place settings

The contextual menu (C-q)

In-place settings (C-q s)

Account stats & quotas (C-q S)

Remote access

Summary & Getting Started

Claude Code, Codex, Cursor and Antigravity under one tool

The fragmentation of AI CLIs

One protocol for all four

Under the hood: Adapting to four different engines

Claude Code (claude_code)

Codex (codex)

Cursor (cursor)

Antigravity (antigravity)

Depth over breadth

Side-by-side comparison

Managing rate limits across providers

One screen, any agent

From one agent to five: what changed in my day

“Which tab was that again?”

A name for every agent, and a parent for its children

Everything in front of my eyes

More than one AI CLI, the same way

Agents that survive a reboot

The numbers

Choosing where the next task goes

What’s still missing

Try it

Plans: split a feature into tasks and let agents run them

Why big features break single prompts

Brainstorm first, let an agent write the plan

Anatomy of a plan: the YAML

Running the plan: slots, worktrees, and context handoff

Watching the graph unfold: CLI and TIDE

Landing tasks: atomic rebases and landing checks

When tasks fail: resolving conflicts with retries

From single plans to plans of plans

Stacked pull requests

Try it

I built wdx with wdx: a team of AI agents wrote most of its code

The next-generation warden

One agent, slowly, on purpose

Design before code

From approved design to a plan that runs for hours

Five or six agents, sometimes fifteen

One CLI first, the others after

What still needs a person

Try it

Run Claude Code and Codex side by side on one repo, without stepping on each other

Why one checkout breaks with two agents

Start each AI CLI in a worktree of its own

Watch both from one screen

Let them talk to each other

The contextual menu (`C-q`)

In-place settings (`C-q s`)

Account stats & quotas (`C-q S`)

Claude Code (`claude_code`)

Codex (`codex`)

Cursor (`cursor`)

Antigravity (`antigravity`)