Workspace chat

Workspace chat is a coding agent that works on one Workspace. It answers from the knowledge files, the knowledge graph, and the linked code of the Workspace, and it can edit the Workspace repository for you.

Start a conversation

Open a Workspace and type in the composer. Your first message creates the conversation and gives it its own URL. The sidebar shows your five most recent conversations under each Workspace.

I am new here. What are the main services, and which files should I read first?

Which services depend on the billing events stream, and where is that implemented?

Before we change authentication, which decisions and standards apply?

To stop a reply, choose Stop. If a reply stops before it ends, choose Retry to send your question again.

How chat finds answers

Each answer can use:

• the knowledge files of the Workspace, and the content that connectors mirror;
• the knowledge graph built from the links and claims in those files;
• code search across the linked repositories;
• the earlier messages of the conversation.

Chat sees only this Workspace. It does not search other Workspaces of your organization.

Change files

Ask the agent to write or update knowledge:

Write a knowledge unit for the checkout service from what you found, and link it to the payments service.

While the agent works:

• Files shows the Workspace repository as this conversation sees it. You can edit, create, rename, and delete files there yourself.
• Diff shows all the changes of the conversation, or the changes of one turn. Use Split view to compare the two versions side by side. Each turn that changes files also shows a card with its changes in the thread.

Each conversation works on its own branch, ctxpipe/chat/<conversation>/<n>, and never pushes to the default branch. The agent commits its work when it finishes a task.

Publish with a pull request

The header of the conversation has these actions:

• Sync (the cloud-upload icon) shows when the sandbox has changes that GitHub does not have. It commits all changes in the sandbox, yours and the agent's, and pushes the branch of the conversation.
• Create PR opens a pull request from the branch of the conversation to the default branch.
• Show PR opens that pull request while it is open. Later pushes go into the same pull request.

Review and merge the pull request like any other. After the merge, the Workspace indexes the new commit, and the next message continues on a new branch (…/<n+1>) from the new default branch. A pull request that is closed without a merge keeps its branch. Choose Create PR again to open a new one.

If the default branch moves while a conversation is open, ctxpipe brings the conversation up to date before the next message. Until then, a conversation with its own changes shows The Workspace has new commits, and you cannot publish it. Send a message to bring it up to date. If the update has a conflict, the agent resolves it.

Where the agent runs

Each conversation runs in its own isolated sandbox, with a copy of the Workspace repository. The first message can take longer while the sandbox starts (Setting up sandbox). Later messages use the same sandbox.

On hosted ctxpipe, each conversation gets its own Vercel Sandbox microVM. No other conversation or organization shares it.

• Your files stay. A sandbox stops after 5 minutes without use and keeps its files. Your next message starts it again, with the files where the agent left them. ctxpipe deletes the saved files 29 days after the last use of the conversation. Before that, it pushes the commits that are not on GitHub to the branch of the conversation. Changes that nobody committed are deleted.
• The agent can use the internet, for example to read documentation or install packages.
• No credential is in the sandbox. A firewall outside the sandbox adds each credential to a request on its way out. The GitHub token can only read, it is short-lived, and ctxpipe revokes it when the sandbox stops. Access to the model and the Workspace tools is added only while a reply runs.

The sandbox never holds a credential that can push to your default branch. Model calls, Workspace tools, and pushes go through ctxpipe, limited to that conversation.

Sandbox limits

An organization runs at most 50 sandboxes at once. Chats, background jobs, and the preparation of Workspace sandboxes all count. Ingestion can use at most 40, so chat always has 10.

When your organization is at the limit, chat shows Workspace chat is at capacity. Wait a few minutes and try again. An ingestion that waits shows Waiting for a free sandbox, and starts by itself when a slot is free.

These limits keep the work of an organization fair. They are not spend limits. If they are not enough for your team, contact us.

Check important answers

Chat can miss a file, read an index that is a few minutes behind, or state a relationship too strongly. For important answers:

• ask which files support the answer;
• ask what is verified and what is inferred;
• check the indexing status in Settings;
• read the current code before a risky change.

Each person who can read the Workspace repository can read the content that connectors mirrored into it. The access settings of the repository therefore also control who can read captured Slack threads and mirrored Linear, Notion, or Confluence content.

Use the same context from your coding agent

Coding agents read the same Workspaces through the ctxpipe MCP. The MCP tools search and read the Workspace directly. They do not start a Workspace chat, so no MCP call adds a conversation to the sidebar.