Shared Terminal — Making ZAgent the Swiss Army Knife of Network Security

Original article by Brian | "The Last Humans"

June 10, 2026

---

This is the second article in the "Give LLMs a Chance to Be Human" series. Core thesis: The Shell Session provided by ZAgent enables LLMs to leverage their extensive "knowledge" to inspect and maintain network security through shells (various commands and tools). It is the Swiss Army knife of network security.

---

1. Why Is "Can Execute Commands" Not Enough?

Many AI coding tools and Agent tools now support shell tools. When a user tells the Agent: "Run the tests for me," the AI Agent executes:

npm test

And returns the result to the user. This capability is already useful. However, when the scenario shifts from "local project development" to "server maintenance," "online troubleshooting," or "security diagnostics," things become more complex.

For example:

• Server requires SSH login
• SSH login may need passwords, keys, bastion hosts, MFA
• May require sudo after login
• Some commands continuously output logs
• Some commands pause waiting for user input
• Some operations require real-time human judgment on whether to proceed
• In production environments, users want to see exactly what the Agent executed

If an Agent only has a regular shell tool, it typically functions like a "background command executor":

User sends message → Agent executes command → Agent returns result

Users see only the result, not the complete process.

However, ZAgent's shared Shell Session provides an alternative approach:

Users and Agents connect to the same real terminal session

This might seem like a small change, but in scenarios like remote server maintenance, security diagnostics, and production troubleshooting, it makes a significant difference in experience.

---

2. What Is a Shared Shell Session?

In ZAgent, a Shell Session is not a one-time command executor but a long-lived shared terminal session. It can be roughly understood as:

A real terminal environment is started when the project launches. Users can operate it in the Shell Tab (terminal tab), and the Agent can also operate it through the shell tool. Both use the same session.

This session has several key characteristics:

• Persistent: Not starting a new process for each command, but maintaining shell state long-term
• Shared: Users and Agent use the same shell
• Subscribable: Shell Tab can continuously receive terminal output
• Interactive: Users can directly input content, such as passwords, confirmation information, Ctrl+C
• State-aware: System can know whether current state is idle, executing commands, waiting for input, or if user has intervened
• Real terminal adapter: Uses PTY underneath, closer to real terminal behavior

So it's not simply executing terminal commands and then getting the execution results. It's more like:

Open a real terminal → Both human and Agent collaborate within this terminal

The shared Shell Session is more like a collaborative terminal:

User inputs commands  ┐
                      ├→ Same PTY Shell Session → Local or Remote Environment
Agent executes cmds  ┘

It preserves terminal state, such as:

• Current directory
• Environment variables
• Logged-in SSH sessions
• Current user identity
• Whether entered a container
• Whether in a virtual environment
• Commands running in the shell

This means:

Once the user SSHs into a remote server in the terminal, subsequent commands executed by the Agent will also run in this remote server's session.

This is where it delivers the most value. It's like you and an assistant sitting in front of the same computer. You can see them type commands, and they can see the current terminal state. If they encounter a password prompt, they pause and let you input. If the command they're executing is inappropriate, you can immediately press Ctrl+C.

This is the essential change brought by shared terminals:

Agent transforms from a background tool to an observable, takeover-able, interruptible collaborator.

---

3. How to Use ZAgent's Shell Session

A typical usage flow is as follows:

Step 1: Open the Shell Tab

User clicks to switch to the Shell Tab in ZAgent. This tab connects to the shared Shell Session maintained by ZAgent backend. Users can input commands like a regular terminal:

pwd
ls

Step 2: User Establishes Key Environment

For remote maintenance, the user can log into the server themselves:

ssh admin@example-server

If password, MFA, or bastion host confirmation is needed, the user completes it themselves. After successful login, the terminal enters the remote server:

admin@example-server:~$

Step 3: Let ZAgent Take Over the Work

Then, in the chat window, we input:

I have logged into the server. Please use the shell tool to do a read-only server health check and pre-maintenance security diagnosis first. Do not modify any configuration.

ZAgent will now call the shell tool and begin executing server security check commands in the Shell Session created earlier. That is, the commands it executes will directly enter the already SSH-logged-in remote server session.

Since LLMs possess more knowledge than any single IT personnel, their ability to perform security checks on servers far exceeds our own.

Step 4: User Observes in Real-Time

When ZAgent executes commands, the Shell Tab continuously displays output. Users can see what it executed, what the output is, and whether it's stuck.

Step 5: Human Takes Over When Interaction is Needed

If encountering:

• sudo password
• yes/no confirmation
• Remote command waiting for input
• Need for human judgment on whether to proceed

User can directly input the corresponding content in the Shell Tab.

---

4. Scenario Example: Remote Server Security Maintenance

Below is a more complete example explaining why this feature is valuable.

Background

Assume you are responsible for maintaining a business server. Recently you noticed:

• Business responses occasionally slowing down
• Disk space growing relatively quickly
• Colleagues suspecting possible abnormal logins on the server
• You want to do a security diagnosis and basic pre-maintenance check first

This kind of work usually cannot be completed with a single command but requires multiple steps:

• Log into server
• Check system load
• Check disk and memory
• Check failed services
• Check recent logins
• Check open ports
• Check abnormal logs
• Determine if further processing is needed

Traditional Approach

In the traditional way, you need to type commands one by one yourself:

uptime
free -h
df -h
systemctl --failed
last -n 20
ss -tulpn
journalctl -p warning -n 100

Then analyze the output yourself. If the output is lengthy, you need to copy it to AI for analysis. This creates several problems:

• Need to copy terminal output back and forth repeatedly
• AI doesn't know which machine you're currently on
• AI doesn't know the current shell state
• If you need to continue investigating, you need to copy the next round of results again
• Process is fragmented, inefficient

Approach Using ZAgent's Shared Shell Session

1. Log into the server yourself first:

ssh admin@example-server

2. After successful login, tell ZAgent in the chat window:

I have logged into the target server. Please use the shell tool to diagnose the target server, checking system load, disk, memory, failed services, recent logins, open ports, and system warning logs. Before any operation, please confirm with me first and explain the purpose of the operation. Only execute after I confirm.

3. ZAgent can now automatically execute a series of checks in the current SSH session and discover issues. If problems are found, it will provide solutions. After you confirm the solution, it will automatically execute the plan and solve the problems for you.

For example:

hostname
whoami
uptime
free -h
df -h
systemctl --failed
last -n 20
ss -tulpn
journalctl -p warning -n 100 --no-pager

Users can see the output of these commands in real-time in the Shell Tab.

4. The Agent continues to summarize after these outputs:

• Whether current server load is abnormal
• Which disk partition is approaching full
• Whether there are failed systemd services
• Whether there have been abnormal login sources recently
• Which ports are listening
• Whether there are obvious errors in system logs

5. If it finds /var partition usage is high, it can continue to suggest:

du -h --max-depth=1 /var 2>/dev/null | sort -h

6. If it finds a certain service has failed, ZAgent will suggest and wait for your confirmation before executing commands:

systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager

Practical Usage Example

1. In the chat input box, enter:

ssh到myhost

(SSH to myhost)

2. ZAgent will then call the bash tool:

{
  "command": "ssh myhost"
}

3. The terminal displays:

E:\zetaagent\zeta-agent-tauri>ssh myhost
Linux iZuf62tcvveb2qzgzd0cutZ 6.1.0-41-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.158-1 (2025-11-09) x86_64
...

4. After logging in, ZAgent analyzes the server and recommends the following commands:

df -h
ss -tulpn
journalctl -p warning -n 50 --no-pager
last -n 20
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

5. ZAgent then asks the user:

Do you need me to help you execute these fix operations?

6. If you answer yes, ZAgent will execute the fix commands above.

The above is a practical usage scenario. As you can see, involving ZAgent in daily maintenance work makes our work much easier.

Beyond the above scenarios, when using database clients like psql, mysql, etc., ZAgent can automatically use commands within psql to perform database management operations based on the task.

---

5. Key Points of Human-AI Collaboration

In this process, the division of labor between human and Agent is very clear:

Role	Responsible Content
Human	Log into server, handle credentials, judge risks, confirm high-risk operations
Agent	Execute repetitive checks, read outputs, summarize issues, propose next steps
Shared Session	Carries the same remote session so both parties see the same scene

This model is:

• Safer than "Agent SSHs to server by itself"
• Smoother than "Human manually copies output to Agent"

---

6. Precautions and Warnings

Letting ZAgent log into remote servers and automatically audit and execute commands may produce high-risk operations. Therefore, you should confirm some high-risk commands before letting the Agent operate, and data backups should be made before certain operations.

The following commands require your confirmation before execution:

• rm
• chmod
• chown
• systemctl restart
• kill
• Package manager install/uninstall
• Database write operations