DOCS · AGENT

Coding agent

Cortex uses OpenCode as its coding-agent engine and provides a focused browser surface for supervising autonomous work.

Focused session surface

The main view contains agent identity and state, a browser-selected workspace, the streamed execution transcript and a resizable composer. Session tabs remain above it for parallel work.

Visible execution

Assistant text, tool calls, commands, completion states and errors stream into the transcript. Tool states remain semantic and assistant responses receive conservative, non-destructive Markdown highlighting. Literal heading, emphasis, inline-code and fenced-code markers remain present, and Copy session returns the original text rather than rendered HTML.

Recovery

Some headless OpenCode runs can complete without emitting final assistant text or usage data to stdout. Cortex captures the OpenCode session identity and exports the isolated session after successful runs, recovering missing response and accounting information from persisted step data.

Multiple durable sessions

Each Cortex tab is an independent conversation and can point at a different workspace. Open and archived sessions are stored by the server in SQLite, including their transcript and OpenCode session identity. A browser-local cache supports the interface and is imported once for installations upgrading from the earlier browser-only format.

Use the menu for a fresh conversation in the current workspace, a new workspace, or restoration of an archived conversation. Server-side persistence means these sessions survive browser refreshes and can be loaded after signing in from another browser.

Agent-run history

Cortex records each run separately from the conversation snapshot: prompt, state, start/finish times, OpenCode session identity, token counts, estimated cost and error details. This provides durable execution evidence while the conversation remains the readable working history.

Authority

The agent can edit files and run commands with the operating-system authority of the Cortex process. The configured workspace root limits which directory can be selected through Cortex, but this remains a high-authority development tool.

Agent-first interface

Cortex intentionally does not embed a conventional code editor. Choose a directory, give the agent a task, inspect its evidence and tool activity, and open another session when you want parallel work.

Workspace confinement

Before browsing, previewing, restoring or launching, Cortex resolves the selected path against its canonical workspace root. Symlink chains that leave that root are rejected. Directory listings are limited to 5,000 entries and regular-file previews to 2 MiB.

This does not sandbox OpenCode from the operating-system account running Cortex. Give that account only the host access you intend the agent to possess.

Lifecycle and limits

Cortex runs at most four OpenCode agents concurrently. Each receives an opaque run ID and remains owned by the authenticated Cortex process until completion or cancellation. Stop, browser disconnect and request cancellation terminate the run; Unix builds terminate the child process group.

Commands are formed as an executable plus argument array rather than shell text. OpenCode is still auto-authorized inside the selected workspace, so the host account and workspace selection remain meaningful security boundaries.

Hostile output and truncation

Cortex treats provider NDJSON, Markdown and error strings as hostile input. A line may be at most 1 MiB; a run stops after 4,096 events or 32 MiB. The transcript receives an explicit truncation notice rather than silently presenting partial output as complete.

Model text is emitted through text nodes, not injected HTML. The small Markdown subset permits only HTTP(S) links with opener isolation. A provider may report a tool event, but only Cortex outer lifecycle events can mark a run done or failed.