Issue: Command Terminal Lacks Support for Persistent/Long-Running Processes

[sudo-eugene]

The Command Terminal doesn't properly support long-running processes like npm run dev, docker-compose up, or tail -f. There's no clear way to terminate these processes, and their continuous output creates excessive noise in the message-style interface.

I checked the documentation at docs.runmaestro.ai and didn't find any guidance on running persistent processes in the Command Terminal, or how to terminate them.

Current Behavior

When running a persistent process like npm run dev:

1. No obvious way to kill the process – Standard terminal conventions like Ctrl+C don't appear to work (or it's unclear if they do)
2. Output treated as chat messages – Each output line or chunk appears as a new "message" in the terminal, creating visual clutter
3. No process status indicator – There's no indication that a background process is still running
4. Accumulating noise – File changes trigger rebuild output, and each rebuild adds more messages, making the terminal hard to follow

Example

> npm run dev

# Initial startup output appears as message 1
# File change triggers rebuild - new message 2  
# Another file change - new message 3
# ... eventually dozens of messages for a single dev session

Expected Behavior

For long-running processes, I would expect:

1. Clear termination method – Either Ctrl+C in the terminal, a stop button, or a keyboard shortcut
2. Streaming output in a single block – Continuous output should append to the same output area, not create new messages
3. Process indicator – Visual indication that a process is running (and which one)
4. Clean separation – Distinguish between "command executed" vs "process still running"

Questions / Clarification Needed

• Is this a bug or intentional design? The message-style interface works great for discrete commands, but seems mismatched for persistent processes.
• What's the intended way to kill a running process? If there is one, it's not discoverable.
• Should persistent processes be run in the Command Terminal at all? Or is the expectation that users run these in an external terminal?

Workaround (Current)

Currently I'm unsure how to cleanly stop npm run dev without:

• Closing and reopening the agent
• Running the dev server in a separate terminal window outside Maestro

Impact

This affects common development workflows where you need:

• Dev servers running (npm run dev, yarn start, python manage.py runserver)
• File watchers (nodemon, cargo watch)
• Log tailing (tail -f, docker logs -f)
• Database CLIs with persistent connections

[pedramamini]

the clear command is "special" and will clear the history, but you are right about all of this. we are running a real interactive shell but rather shooting out one off commands. let me look into improving this experience. one thing to consider is that the current simple approach allows for easy support of remote SSH agents.

[pedramamini]

I think I'm going to upgrade us from what we have now, which is better than the ! mode of Claude Code, to a full terminal implemented via xterm.js. I've got an auto-run doc pending and will look at this for 0.15.x

[nealrauhauser]

The correct manner to deal with this on remote systems would be to support the automated start and maintenance of a tmux instance. The system logs in using ssh keys, starts commands in virtual terminals, turns on logging, and then can disconnect. If the user's network breaks, workstation reboots, etc, the remote processes continue running. The logs are there to consult if something breaks. These same methods would, of course, work locally as well.

This is how those of us with headless systems have long done things. You absolutely want to support the client/server, scriptable tmux, rather than the much older BSD screen utility.

Once this is available it becomes easy to start adding support for Docker, Microk8s, Proxmox, etc.

I'm poking around with Claude Code, but I am NOT a TypeScript guy, probably going to leave this to someone who can troubleshoot, since ssh + remote processes is liable to require some finesse.

[pedramamini]

Auto Run Docs to bring this feature into (initial) fruition:

README.md
Terminal-1.md
Terminal-2.md
Terminal-3.md
Terminal-4.md
Terminal-5.md
Terminal-6.md
Terminal-7.md
Terminal-8.md
Terminal-9.md
Terminal-10.md
Terminal-11.md
Terminal-12.md
Terminal-13.md

[pedramamini]

@sudo-eugene just a heads up I'm closing this in favor of #160, you'll see why soon!