term2

term2 began as a conversational terminal assistant and grew into an application-owned agent runtime. It is designed for working on local codebases and remote servers while keeping the execution model visible and controllable.

The work is in the control plane around the model: how a turn enters the system, how tools are exposed, how commands cross a safety boundary, how context survives long sessions, and how delegated work returns without consuming the main conversation.

The engineering problem

Coding agents sit at an awkward intersection. They need broad access to be useful, but that access must be understandable. They need to stream quickly, but also persist enough state to resume and rewind. They need to support new model providers without letting provider details leak through the whole application.

An application-owned runtime

The runtime is implemented directly in TypeScript rather than delegated to a provider-specific agents SDK. A provider registry keeps model transports at the edge, while the main turn path separates conversation admission, queued execution, turn coordination, streaming normalization, persistence, approvals, retries, and tool dispatch.

That separation lets the same runtime power both the interactive React/Ink interface and a non-interactive CLI. It also makes provider behavior testable through dedicated black-box suites instead of assuming every OpenAI-compatible endpoint behaves the same way.

Read the current architecture overview for the complete lifecycle.

One runtime, five ways to work

The current system exposes five purpose-built operating modes:

• Standard for full codebase work, with workspace patches approved automatically.
• Plan for read-only investigation and implementation planning.
• Lite for fast, read-only terminal assistance.
• Mentor for bringing a separate expert model into a difficult decision.
• Orchestrator for delegating tool-backed tasks to specialized subagents.

These modes share a runtime, but each one changes the available tools and the control policy.

Tools as a script

Since 0.22, the main tool path is run_code. Instead of one tool call per round trip, the model writes a short script against a tools namespace, and each tool declares the shape of what it returns so the script knows what to expect. Tool calls made inside a script still go through the host’s approval path, and the UI shows the nested calls as a trace. MCP servers (stdio, HTTP, or SSE, including OAuth-backed ones) plug into the same path.

Version 0.30 adds script-composed child agents through agent.run, agent.start, agent.status, agent.result, and agent.cancel. A per-invocation agent specification describes the goal, context, tools, constraints, completion criterion, model policy, and budget. The host narrows child permissions to the parent’s authority and pins the worktree scope. Approval-interactive foreground children retain their continuation while the session handles the decision.

Direct subagent tools and role presets remain compatibility paths. Script-launched agents do not yet replace every stored-run continuation or specialized role contract. The delivery report records both the verified session-owner behavior and the remaining live-provider/UI verification limits.

Guarded execution without approval fatigue

The original version treated approval as a single yes-or-no gate. The current design is more deliberate: sandbox read policies protect sensitive paths, shell approval can be manual, advisory, automatic, or always-on. The always setting disables the shell sandbox, so it is an explicit relaxation of protection rather than another safety level. A hybrid heuristic and LLM evaluator approves safe read-only and in-workspace commands on its own, and an optional shadow reviewer can second-guess approval decisions.

Prompting for everything trains users to click yes without reading. This setup keeps consequential actions visible without asking for approval on harmless work one command at a time.

Durable and delegated work

term2 persists conversations as event logs, supports resuming prior sessions, and can rewind to an earlier user turn before editing or resending it. Sessions are indexed in SQLite with full-text search, so the agent can look up earlier work across the project. Provider-neutral context compaction keeps long conversations usable, and when one gets too long anyway, session_rollover hands it off to a fresh session, carrying live background work with it.

For larger jobs, task-shaped child agents and role presets can investigate or implement in parallel with explicit model policies and execution budgets. Background shell work is monitored through the same task interface, keeping foreground turns responsive while preserving a visible record of what is still running.

Sessions can carry an explicit goal and completion criteria across resume and rollover. A git checkout and its worktrees share the project’s session list and memory scope. An opt-in local control socket lets another process inspect, submit, steer, or interrupt a live terminal session.

Remote and provider-flexible by design

The provider layer supports OpenAI, ChatGPT/Codex OAuth, Grok, OpenRouter, Anthropic, Gemini, and local OpenAI-compatible endpoints such as Ollama, llama.cpp, and vLLM, all reachable from one cross-provider model picker. Native SSH mode applies the same agent workflow to remote text files and command execution without installing term2 on the target server. A web gateway exposes sessions to external clients with authentication and durable recovery.

Background shell jobs remain local-only. Remote shell execution should not be assumed to inherit the local shell sandbox. Providers and remote environments still behave differently. Those differences stay behind explicit boundaries, so the rest of the system deals with one workflow.

Current snapshot

Released version 0.30.0 (29 September 2026) includes:

• A first-party TypeScript agent runtime
• Five operating modes, task-shaped agent specifications, and compatible role presets
• Provider registry and multiple model transports
• run_code scripted tools, MCP servers, and child-agent composition with approval continuation
• Native local and SSH workflows
• Sandbox policies and graduated approvals
• Resume, rewind, fork, usage accounting, and model handoff
• SQLite session index with full-text search, durable goals, and session rollover
• Shared git-project session/memory scope and an opt-in local control socket
• Provider-neutral context compaction and recovery
• Monitored background agents and shell jobs
• Interactive Ink UI, non-interactive CLI with NDJSON output, and a web gateway

The inspected main revision, 36d7cdc (30 September 2026), also includes remote run_code filesystem-authority support. This is a post-release source change; it is not presented here as part of the published 0.30.0 package.

See the documentation site, source repository, changelog, and architecture documentation for the latest state.