# Workspace chat (https://docs.ctxpipe.ai/docs/workspaces/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. ```text I am new here. What are the main services, and which files should I read first? ``` ```text Which services depend on the billing events stream, and where is that implemented? ``` ```text 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](/docs/workspaces/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: ```text 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//`, 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 (`…/`) 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](https://vercel.com/docs/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](/docs/getting-started/get-in-touch). ## 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](/docs/mcp/mcp-docs). 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.