Workspace

What a workspace is

A workspace is an interactive chat session with a Claude agent that has scoped access to one of your codebases. The agent can read files, search for patterns, and propose concrete changes — but it never writes to disk on its own. Each session is bound to a project (codebase + connection) and can optionally be linked to an issue.

The workspaces list

The Workspace index is a DataTable — same primitives as Issues, Projects, and Knowledge:

Server-side sort + filter, saved views, column visibility, CSV export.
Keyboard nav (j / k, / to focus search, Enter to drill in, Esc to clear).
Row activation routes to /workspace/:id. The detail page records the list context so [ / ] step prev/next under the filter you came from.
Sticky toolbar + column header — long lists stay scannable while you keep the search input in reach.

Bulk actions on the list are deliberately limited (rename / delete) — the working surface is the chat itself.

Keyboard map and command-palette commands: see Keyboard & command palette.

Starting a session

Go to Workspace in the sidebar and click New code session.
Pick a project — the codebase, branch and connection are resolved from the project profile.
Give the session a title (e.g. "Fix payment metadata"), optionally a linked issue key (e.g. BIZ-29), and a short instruction.
Click Start session. You land directly in the chat.

From there you ask questions, request changes, or attach screenshots and files — like a normal chat, but with full codebase context.

What the agent can and cannot do

The agent can explore your codebase — list directories, read files, and search across source — and it can propose changes. What it never does: write directly to your files. Every change flows through the Patch panel and lands only after approval — by default when you click Apply, or automatically as a pull request when the project opted in to auto-delivery.

In trusted mode the agent may additionally run shell commands and fetch web pages. Restricted mode disables those (see below).

Patch approval flow

When the agent proposes a change, the Patch panel on the right shows each affected file, a diff view, and any notes. None of it touches your codebase until you say so:

Approve — mark the patch as accepted.
Apply — write the changes to your working copy or branch.
Reject — discard the proposal, optionally with feedback so the agent produces a revision.

Each patch is versioned. Earlier versions stay visible so you can review what you turned down.

If the session is linked to an issue with a running mission, an approval gate can appear above the patch (for example a CTO gate). The patch panel defers to that gate: you handle the gate first. See Approvals for how plan and patch gates work.

Persistent memory

A session remembers the whole conversation. Earlier messages, files the agent has already read, and feedback you've given remain available across turns — through reloads and across days. Long threads are condensed so the agent keeps continuity without re-reading every old message verbatim.

Trust modes

Two modes, configured under Settings → AI:

Trusted (default for desktop) — the agent can run shell commands and fetch web pages alongside reading the codebase. File mutations remain behind the Approve gate.
Restricted (hosted / multi-tenant) — shell access and web fetching are turned off. Recommended for shared infrastructure.

FAQ

Does the agent edit files itself? No. File-mutating tools are always blocked. A patch reaches your repo only through approval — Apply by hand, or as an automatically opened pull request when the project opted in to auto-delivery.

Can I resume a session? Yes — reopen it from the Workspace list. History persists until you delete the session.