Build a Development Workspace

Outcome: one named session with editor, tests, and logs windows, all starting in your project directory. Running the setup again returns to the existing session without creating duplicate windows or launching extra processes.

You need tmux installed, Bash, and an existing local project. For a remote project, SSH into the host first. Run the setup from a terminal outside tmux so the final attach does not create a nested session.

Create the workspace once

Save this as dev-workspace.sh in your project. Run it with bash dev-workspace.sh from that project's root directory. It creates three shell windows; you choose the application commands afterward.

#!/usr/bin/env bash
set -e
 
if [ -n "${TMUX:-}" ]; then
  printf '%s\n' 'Detach first, then run this script outside tmux.' >&2
  exit 1
fi
 
workspace_session='dev-workspace'
workspace_dir="$PWD"
 
if ! tmux has-session -t "=$workspace_session" 2>/dev/null; then
  tmux new-session -d -s "$workspace_session" -n editor -c "$workspace_dir"
  tmux new-window -d -t "=$workspace_session:" -n tests -c "$workspace_dir"
  tmux new-window -d -t "=$workspace_session:" -n logs -c "$workspace_dir"
  tmux select-window -t "=$workspace_session:editor"
fi
 
tmux attach-session -t "=$workspace_session"

Choose a unique workspace_session name per project before the first run. The quotes preserve spaces in the project path, -c sets each window's starting directory, and exact session targets avoid matching similarly named sessions. No window indexes are assumed, so this also works with a custom base-index. The tmux 3.7c manual documents these commands and target rules.

Put each window to work

Press Ctrl+b w to choose a window by name. Release Ctrl+b before pressing w. From each shell prompt, launch the command you normally use for that task:

These examples are choices to adapt, not commands the setup script starts. Keep using your project's existing test and logging conventions. A test command that finishes leaves you at a shell prompt ready for the next run. Ctrl+c stops a foreground log reader without closing its window.

Want two tasks visible at once? In a chosen window, Ctrl+b % splits left and right, and Ctrl+b " splits top and bottom. Ctrl+b o changes the active pane; Ctrl+b z temporarily zooms it. A new pane starts another shell, so check pwd before launching a project command. The official getting-started guide covers windows, panes, and navigation.

Verify and return later

Before starting applications, run this in any workspace shell:

tmux list-windows -t '=dev-workspace' -F '#{window_name}'

With an unchanged setup, you should see editor, tests, and logs. Run pwd in each window to confirm its project directory.

Press Ctrl+b d to detach, then run bash dev-workspace.sh again from the project root. You should return to the existing workspace. Repeat list-windows: the setup still has three windows unless you added or removed some yourself. Applications you started remain as you left them while their processes and the tmux server are running.

What repeatable setup means here

The session check makes this script idempotent for an existing session: subsequent runs attach and skip all creation commands. They do not restart tests, duplicate logs, change working directories, or reset your layout. An existing session with the same name is reused even if it belongs to a different project, so the name matters.

This is a create-once script, not a repair tool. If the first run fails halfway through, the partial session remains; later runs attach to it. Inspect its windows and add the missing one manually, for example from a workspace shell in the correct project directory:

tmux new-window -d -t '=dev-workspace:' -n logs -c "$PWD"

Only run that repair if the logs window is missing. The check and creation are separate operations, so do not launch the setup concurrently. After a reboot, the script can recreate the shell windows; it cannot recover unsaved editor state or running processes.

Tune the workspace

Open the development config preset for a starting configuration, then validate your edits. The generator creates configuration text; the script above creates this workspace.

Practice pane navigation or try the playground before working with live processes. Those browser simulations do not run this script, your editor, tests, or log commands. For real remote persistence, follow the SSH session check.