Chat in Claude Desktop on 3P

Chat in Claude Desktop on third-party (3P) is a conversational surface for quick questions and drafting. Unlike Cowork and Code, which run agentic sessions with access to folders you grant and a code-execution environment, a Chat conversation runs with a deliberately small tool surface: it can search and fetch the web under your admin configuration, read files attached to the conversation, read the project’s memory when the conversation is inside a project, and write files into a scratch space of its own, and nothing else on the machine. Chat is off by default and is enabled with a single configuration key. Like everything else in 3P mode, Chat conversations run against your configured inference provider, and conversation history lives on the user’s device. See User identity and local data for exactly what is written where and what can leave the device.

​

What a Chat conversation can reach

disabledBuiltinTools and builtinToolPolicy apply in Chat the same way they do in Cowork and Code sessions. For example, adding "WebFetch" removes web fetch from Chat conversations too.

​

What a Chat conversation cannot do

In a Chat conversation, Claude cannot:

• Read or write the filesystem beyond the conversation’s own uploads and scratch directories and, inside a project, the project’s memory (read-only). Chat conversations never receive folder access: the tool for requesting folder access is removed, and the app refuses folder grants to a Chat conversation even when requested through internal interfaces.
• Run code on the host. There is no shell access. With advanced file analysis off (the default), the sandbox VM is never started for Chat; with it on, code runs only inside the offline sandbox described below, never on the host itself.
• Act without asking. Chat conversations always run in the default permission mode. Auto mode and other reduced-supervision modes are rejected for Chat regardless of autoModeEnabled.
• Create or run scheduled tasks, or list the ones that exist.
• Escalate into an agentic session. The tools that launch Code sessions or dispatch background agent tasks are removed. When a request needs capabilities Chat doesn’t have, Claude says so and suggests starting the task in Cowork instead.
• Read other conversations. The tools that list sessions or read other sessions’ transcripts are removed, so a Chat conversation cannot search or quote your other chats, Cowork sessions, or Code sessions.
• Write memory. Chat conversations cannot add to or change memory; inside a project they read the project’s memory as described above, and outside a project they use no memory.

These restrictions are enforced in the app’s main process, not just hidden in the UI.

​

Advanced file analysis

By default, Chat can read attached files only in the formats Claude understands natively. Setting chatAdvancedFileAnalysisEnabled to true lets Claude also run code against attachments. This is useful for spreadsheets, PowerPoint files, and other formats that need parsing, and for inline data analysis on attached data. The execution environment is intentionally narrower than the Cowork sandbox:

• Code runs in the same isolated local VM that Cowork uses. For Chat, the VM starts only when analysis is coming: on the first analysis call, or at the start of a turn with files attached.
• The sandbox has no network access. This is unconditional for Chat and independent of coworkEgressAllowedHosts: an allowlist that opens egress for Cowork sessions does not open it for Chat analysis.
• The only conversation data the sandbox sees is the conversation’s attached files (read-only), its scratch directory (writable), and, for a conversation inside a project, that project’s memory (read-only), plus read-only reference material bundled by the app. No user folders, and no other sessions’ working directories or transcripts.
• Each command runs independently; results land in the scratch directory, where Claude can offer them to the user as downloads or artifacts.

The data flow end to end: an attached file is copied into the conversation’s local uploads directory, mounted read-only into the sandbox when analysis runs, and any outputs are written to the conversation’s scratch directory on local disk. File content leaves the device only as conversation context sent to your configured inference provider, in web search queries to your configured search backend, through web fetches your egress allowlist permits, in a connector tool call permitted by your toolPolicy configuration and the user’s approvals, or, if you have enabled content capture, in telemetry to your own collector.

​

Configuration

When chatTabEnabled is true, Claude Desktop presents Chat and Cowork together as Home in its sidebar, next to Code. From Home, the user chooses Chat or Cowork in the message box, and the sidebar lists chats and tasks together. When the key is unset or false, the sidebar shows Cowork in place of Home and the message box offers no choice. If coworkTabEnabled is false while Chat is enabled, the message box offers Chat only. Enforcement of chatTabEnabled happens in the app’s main process: when the key is unset or false, Chat does not appear in the app, and the app additionally refuses to start or continue a Chat conversation, including conversations created before an admin turned the key off. The rule that at least one surface must stay enabled counts Chat only when chatTabEnabled is explicitly true: a configuration that disables Cowork and Code without enabling Chat re-enables Cowork with a validation warning, rather than leaving users with an empty app. With chatTabEnabled set to true, a chat-only configuration is valid.

​

Where Chat data lives

Chat conversations are stored on the local device, in the same per-session layout as Cowork sessions: conversation history, attachment copies, scratch outputs, and a tamper-evident audit log, all under the application-data directory. Nothing is synced to a server, and there is no server-side index of past conversations. See Chat conversations on the data-storage page for the breakdown.