[Feature Request]: Interactive Session Detection and Terminal Forwarding for LLM Agents

[nguyentrongduy]

Describe the feature
I would like to propose a feature that allows abtop to detect and manage interactive sessions where an LLM agent (such as Claude Code, Codex, or other CLI-based agents) is idling and waiting for user input.

Specifically:

Interaction Status Indicator: A visual flag or status column in the dashboard to identify sessions currently blocked by a prompt (e.g., waiting for y/n confirmation, file access permission, or command execution approval).

Terminal Interaction/Forwarding: A way to "attach" or forward the terminal input directly within abtop (similar to how one might use docker attach or a screen/tmux session) to respond to the prompt without switching back to the original process terminal.

Use case
When running multiple AI agent tasks simultaneously, it is often difficult to track which process has paused because it requires manual intervention.

Problem: Currently, if an agent asks for permission to read a sensitive file or run a shell command, the session appears "active" or "idle" in monitoring, but the user doesn't know why it's not progressing until they manually check that specific terminal tab.

Solution: This feature would centralize the management of interactive prompts, making abtop not just a monitoring tool but a control hub for multi-session AI workflows.

Additional context
As tools like Claude Code and other autonomous agents become more common, they frequently implement safety guardrails that require human-in-the-loop (HITL) confirmation.

Ideally, selecting a session in abtop could open a small interactive sub-pane or provide a shortcut key to "Respond" to the pending prompt.

This would align abtop with the needs of developers managing complex, long-running agentic tasks on local or remote infrastructure.

[graykode]

Thanks for the detailed request.

I agree that detecting sessions blocked on human input would be useful, especially when several agent sessions are running at once. The main challenge is that Claude Code, Codex, and OpenCode do not currently expose a stable machine-readable state for “waiting on a permission prompt” or “blocked on user confirmation”, so this would likely need to start as a best-effort heuristic.

The terminal forwarding part is more complicated. Attaching to an already-running process terminal and safely forwarding input is not generally reliable unless the session is already managed by something like tmux or screen. It also carries some safety risk because abtop could end up sending input to the wrong prompt or terminal state.

abtop already has a tmux-based jump feature via Enter, which switches to the pane that owns the selected agent session. I think the safer path is to improve that workflow first, and separately investigate better indicators for “waiting for user input” based on transcript/process activity.

I’ll keep this open as a tracking issue for improved interactive/waiting detection, but I’d treat direct terminal forwarding as a separate, higher-risk feature.