Terminal Access
Terminal Access
Characters can execute shell commands on the host machine through a multi-layered security system. Terminal access is powerful — a character can check system status, manage files, run scripts, and interact with the operating system — but it's carefully controlled.
How Terminal Access Works
When a character has the Terminal node enabled and needs to run a command, it includes a trigger in its response:
[TRIGGER:terminal:ls -la /var/log]
The command passes through five security layers before execution:
- Dangerous pattern check — hardcoded patterns that are always blocked (fork bombs, recursive root deletion, disk formatting)
- Whitelist — commands in the active preset's allowed list pass through
- Blacklist — explicitly blocked commands are rejected
- Path validation — commands accessing paths outside allowed directories are blocked
- Terminal Service safety checker — a second independent safety layer at the execution point
Only commands that pass all five layers are executed. The result is returned to the character for analysis.
Presets
Terminal access is controlled through presets — named collections of allowed commands. Each preset defines what commands the character can run:
| Preset | Commands | Best For |
|---|---|---|
| Read Only | 69 commands — ls, cat, grep, find, curl, ps, df, ping, etc. |
Safe system inspection. Cannot modify anything. |
| Read & Write | 35 commands — mkdir, cp, mv, rm, chmod, tar, nano, etc. |
File management tasks |
| Developer | 61 commands — git, npm, python, docker, make, cargo, etc. |
Development and DevOps workflows |
| System Admin | 46 commands — systemctl, journalctl, useradd, mount, sudo, etc. |
System administration |
| Manual | 0 commands — you define your own whitelist and blacklist | Full custom control |
Presets are additive to your manual whitelist. You can select a preset AND add extra commands to the whitelist.
Enabling Terminal Access
Terminal access is configured in two places:
On the Character (Visual Builder)
Add the Terminal node to the character's canvas. This enables the character to use [TRIGGER:terminal:command] patterns. Configure allowed commands, blocked patterns, and path restrictions in the node settings.
On the User (Concierge Terminal Settings)
For the Concierge assistant specifically, terminal access is configured in the QUI Core dashboard → Chat tab → Terminal Settings:
- Toggle Enable Terminal Access on
- Select a preset (or Manual for custom)
- Optionally add commands to the whitelist or blacklist
- Toggle Require Manual Approval if you want to review each command before execution
Manual Approval Mode
When manual approval is enabled, every command proposed by the character shows an Execute button instead of running automatically. You see the command, decide if it's safe, and click Execute to proceed.
The Execute button bypasses the preset/whitelist filters (since you're explicitly approving), but the Terminal Service's safety layer still blocks inherently dangerous operations.
What's Always Blocked
Regardless of preset, whitelist, or manual approval, these patterns are always blocked by the dangerous command filter:
- Recursive root deletion (
rm -rf /) - Writing to disk devices (
dd of=/dev/sda) - Filesystem formatting (
mkfs) - Fork bombs
- Recursive world-writable permissions (
chmod -R 777) - Piping untrusted URLs to shell (
curl | bash) - Background process detachment (
nohup,disown)
These protections exist at both the QUI Core command filter layer and the Terminal Service safety checker layer — two independent systems that must both pass.
Audit Trail
Every terminal command attempt is logged, regardless of outcome:
- Which user ran it
- The full command
- Whether it was allowed, blocked, executed, or failed
- The exit code and output (if executed)
- Which preset was active
- Execution duration
Audit logs are retained for 90 days and cleaned up automatically.
Terminal in ThinkThing
ThinkThing has 24 terminal node types — one generic and 23 specialized for specific domains (Git, Python, Docker, PostgreSQL, etc.). These nodes use an agentic loop:
- You describe a task in natural language
- The LLM decides what commands to run
- Commands are executed through the security system
- Results are fed back to the LLM
- The LLM iterates until the task is complete or the iteration limit is reached
Each specialized node scopes the LLM to its domain — a "Git Terminal" node focuses the LLM on git operations, while a "Docker Terminal" node focuses on container management.
