Project Shell

The Terminal gives you a live shell rooted in the current project's directory. It's the same workspace-backed filesystem that tasks use, so you can inspect, modify, and test things without going through the task queue.

Each terminal session runs inside its own short-lived sandbox container. The container starts in the current project root, mounts the current workspace storage tree, inherits only explicitly injected runtime variables, and is cleaned up when the session closes or goes idle. That means shell access can also reach sibling workspace-level directories such as .memory or other project folders that live inside the same workspace storage area.

Opening a session

1. Select your project in the sidebar.
2. Click Terminal.
3. Click New Session to start a fresh shell, or click an existing session in the list to resume it.

Each session persists until you close it, it reaches the idle timeout, or the server restarts. You can have multiple sessions open at once.

What to use the terminal for

Inspecting task output: After a task completes, cd into its working directory to review generated files, check logs, or run quick validation commands.

Manual patching: If you need to edit a file before re-running a task (for example, fix a config value), the terminal is faster than uploading a corrected file.

Debugging project setup: Check what tools are installed (python3 --version, node --version, etc.) or verify filesystem structure before writing a prompt that relies on those tools being available.

Running quick one-off commands: Sometimes you just need to grep, curl, or jq something without the overhead of spinning up a full task.

Session controls

Action	How
Start a new session	Click New Session
Resume an existing session	Click the session name in the list
Close a session	Use the close button next to the session, or type exit in the shell

Relationship to tasks

The terminal and tasks share the same workspace-backed filesystem. A file you create in the terminal is immediately visible to a subsequent task, and vice versa. However, they run in separate processes — a shell session you open does not inherit the environment variables set by a task, and tasks do not see commands you ran in the terminal.

The project setting Allow sandbox network access controls outbound network access for both task runs and terminal sessions. Turn it off when you want the project to stay filesystem-only.

Tips

• The terminal uses the shell configured for the project (typically /bin/bash).
• Admins can point sandbox containers at an alternate Docker runtime with runtime.sandbox.runtime if the host has one registered, such as runsc for gVisor.
• Command history is local to each session.
• For large file operations, use the terminal instead of the Files browser — it's much faster for bulk moves, renames, or deletions.