Processes

Process Model

• • Processes are defined at the project level and inherited by each workspace.
• • Each workspace can customize its own process commands independently.
• • Each process has a command and optional name.
• • Each process has an on_exit policy: none, restart, or notify.
• • Typical use cases: web servers, workers, test watchers, coding agents.

GUI Configuration

• • In Workspace Settings, each process row includes an On Exit selector.
• • none: mark exited and do not take action.
• • notify: show a desktop notification when the process exits.
• • restart: automatically restart the process after exit is detected.

Environment Variables

Every workspace process receives reserved ports and workspace path variables.

FRONTEND_PORT, API_PORT, ...   # named port definitions
MUXY_PROJECT_DIR
MUXY_WORKSPACE_DIR

Use these values directly in commands, for example `PORT=$FRONTEND_PORT npm run dev`.

Launch and Runtime

• • On launch, each process starts in its own iTerm2 window.
• • Running processes are tracked per workspace and visible in the Run tab.
• • If workspace settings are edited while running, added processes start immediately.

Stop and Restart Behavior

• • Stop gracefully interrupts processes first, then escalates if needed.
• • The stop script runs after process termination (if configured).
• • Automatic restarts terminate and wait for prior runtime PID exit before relaunch.
• • Command changes in a running workspace restart the affected process in the same terminal window.

Coding Agent Detection

Muxy can classify agent-like process commands (for example `codex` or `claude`) and expose idle/busy semantics in status reporting.

• • Busy: process is running and producing output.
• • Idle: process is running with no output for a configured interval.
• • Exited: process has stopped.