Folder & Desktop Access

Detail

Anthropic’s guidance for Cowork/Desktop is phrased as a suggestion, not a directive: “Consider creating a dedicated working folder for Claude rather than granting broad access, and keep backups of important files.” Both halves matter — the backup companion is part of the same sentence, and it is the recovery plan for the deletion capability the same passage describes: “Since Claude can read, write, and permanently delete these files, be cautious about granting access to sensitive information like financial documents, credentials, or personal records.”

The narrower the folder, the smaller the surface for mistakes: an explicit boundary you chose, instead of everything you happen to keep on your machine. But note what a folder boundary does not do — files Claude opens there are processed on Anthropic’s servers, not kept local (Isolation protects your computer from Claude's code — it does not limit what Claude reads or does).

Source & currency

• Source: Use Claude Cowork safely — Claude Help Center (cited by the source doc).
• Status: CONFIRMED 2026-07-25 (receipt R10): both quoted passages verified on the live page this date. Corrected 2026-07-25 — the prior version rendered the source’s “Consider …” suggestion as “Anthropic’s own guidance … is to create,” and dropped the “keep backups of important files” clause from the same sentence.

Related

• Folder & Desktop Access — parent domain
• Isolation protects your computer from Claude's code — it does not limit what Claude reads or does — what a folder boundary does not keep local
• The three-tier pattern: raw/ work/ out/ — the concrete folder pattern that implements this guidance
• .env files stay out of version control and out of Claude working folders — what must never sit inside the folder you do connect
• Recommended folder structure for isolating each org's files — the working group’s per-org version of this question

Detail

A common pattern recommended by Anthropic and practitioners: three tiers — raw/ (untouched source files), work/ (the only folder Claude is granted access to), and out/ (final deliverables) — so the access boundary is explicit and easy to audit. Originals stay safe by construction; Claude works on copies; outputs land somewhere you review before they go anywhere else.

Source & currency

• Source: the working-group document §1 (practice pattern; attributed there to Anthropic guidance and practitioner practice — no single page cited).
• Status: DOCUMENTED · register: recommendation — practice guidance, not a product behavior of Claude. Currency check 2026-07-22 (receipt R1): the cited Cowork-safety page does not carry the raw/work/out pattern — it stands as the working group’s adopted practice, attributed by the source doc to Anthropic-and-practitioner guidance.

Related

• Folder & Desktop Access — parent domain
• Use a dedicated working folder, not broad desktop access — the guidance this pattern implements
• Reviewing and revoking granted folder access — auditing what was actually touched inside work/

Detail

The source page states the boundary and then immediately warns against over-reading it. Three facts, in the order that matters:

1. What isolation does. “Isolation protects your computer and network from the code Claude runs; it doesn’t change what Claude can read or do through the access you’ve granted.” Said plainly by the page: “Isolation limits where Claude’s code runs. It doesn’t limit what Claude reads or does.” Depending on access granted, a remote session can still “browse the web, read email and documents through your connected apps, work in folders you’ve connected, and take actions through those same channels” — and the page notes each of those is “a path for untrusted content to reach Claude, and for Claude’s actions to reach the real world.”

2. Where your files end up. “Because sessions run on Anthropic’s servers, the work Claude does there, including any local files it opens through the desktop app, is processed on Anthropic’s servers rather than staying on your computer.” A connected folder is not a local-only boundary — it is an ingress to a remote environment. This is the fact that matters for anything sensitive.

3. When the session can reach you (unchanged, still true): “A remote session reaches your computer only when the Claude Desktop app is open, only for the folders you’ve connected there, and with the permissions you’ve already set.” If the desktop app is offline, the session can’t reach your computer. The environment itself is temporary, per-session, can’t reach your home or company network, and is removed when the session ends.

Because the isolation claim is easy to read as reassurance, the page’s own framing is the safe one: reason about what Claude can read and what Claude is allowed to do, not about where the session runs. Related compliance fact: whatever its isolation properties, Cowork is not yet covered under Anthropic’s BAA — see Most ways of using Claude are never covered by Anthropic's BAA — and on two cloud platforms, coverage is someone else's call.

Source & currency

• Source: Use Claude Cowork safely — Claude Help Center.
• Status: CONFIRMED 2026-07-25 (receipt R10) — all three quoted passages verified on the live page this date. This node was corrected on 2026-07-25: the prior version extracted the isolation sentence as reassurance and omitted the off-machine-processing fact, which the source states in the same paragraph.
• ⚑ Compliance-relevant: confirm current specifics with your Anthropic contact before relying on this for anything involving patient data — product behavior moves between releases. This is a teaching aid, not compliance or legal advice.

Related

• Folder & Desktop Access — parent domain
• Claude always asks before permanently deleting files — in any mode — the one action that is gated in every mode
• Computer use: you grant apps, but nothing checks each action — and there is no sandbox — the surface where isolation does not apply at all
• Prompt injection: instructions hidden in content Claude reads — the attack that “what Claude reads” opens the door to
• Most ways of using Claude are never covered by Anthropic's BAA — and on two cloud platforms, coverage is someone else's call — isolation is not the same thing as BAA coverage
• Folder access differences: chat vs Cowork vs Claude Code — how chat / Cowork / Claude Code differ
• Cowork — what Cowork is, plainly

Detail

Deletion protection is stated by the source as unconditional across approval modes: “Claude always asks before permanently deleting files, in any mode.” The mechanism: “Cowork requires your explicit permission before permanently deleting any files. You’ll see a permission prompt and must select ‘Allow’ before Claude can perform deletion tasks.”

Do not generalize this to other actions. The approval modes differ sharply in what else they check: in “Automatically approve” mode, “Claude still reviews each action for safety before it runs”; in “Skip all approvals,” “nothing checks its actions.” Deletion is carved out of that difference — nothing else is. In particular, computer use is a separate surface with a different (weaker) protection model — see Computer use: you grant apps, but nothing checks each action — and there is no sandbox.

This is a guardrail, not a substitute for scoping. The folder boundary (Use a dedicated working folder, not broad desktop access) is the primary protection; the permission gate is the second layer; and a deletion you approve is still a deletion, which is why the source pairs the folder advice with keeping backups.

Source & currency

• Source: Use Claude Cowork safely — Claude Help Center.
• Status: CONFIRMED 2026-07-25 (receipt R10) — both quoted passages verified on the live page this date. This node was narrowed on 2026-07-25: the prior version added “and it’s designed to ask permission before other high-risk actions too,” which over-generalized a claim the source makes only about deletion, and which the computer-use section of the same page contradicts for that surface.

Related

• Folder & Desktop Access — parent domain
• Isolation protects your computer from Claude's code — it does not limit what Claude reads or does — where the session runs and when it reaches you
• Computer use: you grant apps, but nothing checks each action — and there is no sandbox — the surface this gate does not cover
• Use a dedicated working folder, not broad desktop access — the boundary this gate backs up

Detail

Computer use is the weakest-protected surface in Cowork, and its protections work differently from the file-side ones. Four facts, and the distinction between the first two is the whole point:

1. Per-application permission exists. “When Claude uses your computer, it asks for your permission before accessing each application.”
2. Per-action checking does not. The source warns to “be especially cautious with computer use — Claude clicks, types, and navigates your screen directly, without the permission checks that gate other Cowork tools.” So: you decide which apps; you do not approve what it does inside them.
3. No sandbox. “Unlike file operations (which go through permission checks) or code execution (which runs in an isolated environment), computer use has no sandbox between Claude and what’s on your screen.”
4. The app grant leaks through links. “Although it can only use apps that you’ve given it permission to use, if it clicks a link in one app that link will open, even if you haven’t given Claude permission to access that app.” A link is enough to cross the boundary you set.

Also: “Claude takes screenshots to understand your screen” — everything visible is read, not only the app you had in mind.

The source’s own first instruction is the clinical one: “Block sensitive apps (healthcare portals, banking, dating apps) so Claude doesn’t encounter information you’d rather keep private.” Healthcare portals are named first on that list. Do this before a session, not after.

Note the interaction with approval modes: deletion remains gated in every mode (Claude always asks before permanently deleting files — in any mode), but under “Skip all approvals,” “nothing checks its actions” — combined with an unsandboxed screen, that is the widest exposure Cowork offers. And because Claude reads whatever is on screen, this surface is a live prompt-injection vector (Prompt injection: instructions hidden in content Claude reads).

Source & currency

• Source: Use Claude Cowork safely — Claude Help Center — under “5. Be cautious with computer use”, “4. Match your oversight to the stakes”, and the safeguards list. (All quotes are on that page; the separately-linked “Let Claude use your computer in Cowork” article is further reading, not the source cited here.)
• Status: CONFIRMED 2026-07-25 (receipt R10) — all four quoted passages verified on the live page this date. This node was created on 2026-07-25 by splitting the over-general “asks before other high-risk actions” claim off Claude always asks before permanently deleting files — in any mode. Note for reviewers: an external audit proposed teaching that computer use has “no permission check” at all; that is not what the source says — the per-application ask exists (fact 1). What is absent is per-action checking and any sandbox. Both halves are carried above deliberately.
• ⚑ Compliance-relevant: confirm current specifics with your Anthropic contact before using computer use anywhere near patient data. This is a teaching aid, not compliance or legal advice.

Related

• Folder & Desktop Access — parent domain
• Claude always asks before permanently deleting files — in any mode — the one action gated in every mode
• Isolation protects your computer from Claude's code — it does not limit what Claude reads or does — why “isolated” does not cover this surface
• Prompt injection: instructions hidden in content Claude reads — reading the screen is a path for injected instructions
• Folder access differences: chat vs Cowork vs Claude Code — how chat / Cowork / Claude Code differ

Detail

The overview and access article now affirm Cowork coverage (receipts R77, R78). The session reference distinguishes local desktop from remote Cowork sessions and requires an Enterprise account, enabled Compliance API and a Compliance Access Key with the relevant scope. An Admin API key alone cannot retrieve these transcripts (receipt R80). These are documentation checks, not tests against a real organization.

Do not infer coverage from the product name alone. The session reference excludes local sessions under HIPAA readiness or ZDR, and excludes the listed API-key/third-party Claude Code cases and Claude Code on the web. Remote session endpoints concern Cowork; they are not a catch-all for cloud products. Audit-log CSV export, API transcripts and OpenTelemetry are distinct surfaces.

Our recommended check: have the authorized owner verify coverage with a synthetic session for each relevant configuration, including the expected exclusions. No patient information is needed for that check; no API call was made by this curriculum review.

Source & currency

• CONFIRMED 2026-09-16 — receipts R77, R78, R79, R80. Confirmed means the published scope was retrieved, not that a tenant was tested.
• Correction history: on 28 July the product page excluded Cowork; on 3 August the API docs added cloud sessions while the product page still denied coverage. That earlier disagreement was real (R41, R65–R67). On 16 September the product denial no longer appeared in the complete fetched document, and the API references expressly documented local and remote scope. The old cloud-only/no-local-coverage wording is superseded. The pre-C1 node is preserved in the private session evidence.
• ⚑ Compliance-critical: confirm current specifics with your Anthropic contact before relying on this for a compliance decision. This is a teaching aid, not compliance or legal advice.

Related

• Folder & Desktop Access — parent domain
• Cowork activity can be exported through OpenTelemetry — if you can run a collector — separate collector route and its prerequisites
• Compliance API coverage must be checked by product, account and session type — coverage differs by product and configuration
• Cowork — Cowork terminology
• Folder Access — connections — related access and privacy questions

Detail

What gets exported. From the docs: “Cowork exports events via the OTel logs/events protocol, giving you visibility into user prompts, model responses, API requests, tool usage, and errors.” The help-centre article lists the same ground in plainer terms — the events cover “User prompts. The full text of prompts users submit to Cowork”, “Tool and MCP invocations. Every tool call Claude makes during a session, including MCP server name, tool name, parameters, success or failure, and execution time”, “File access. File paths Claude reads, modifies, or otherwise touches during a session, including files accessed through MCPs and folder-scoped local files”, “Skills and plugins. Which skills and plugins Claude invokes within a session”, “Human approval decisions. Whether each tool action was approved by the user, rejected by the user, or initiated automatically based on existing permissions”, and “API requests and errors. Per-request model, token counts, estimated cost, duration, and any errors returned.”

That is a genuinely useful oversight record. Now the four preconditions.

Precondition 1 — plan tier. “Monitoring is available for Team and Enterprise plans.” The help centre states it the same way: “OpenTelemetry monitoring for Claude Cowork is available on Team and Enterprise plans.” Individual and Pro accounts are not in scope.

Precondition 2 — an admin must configure an OTLP endpoint, and nothing flows until they do. “Events are only exported when an admin configures an OTLP endpoint. No data flows by default.” The docs describe where: “Navigate to Admin settings > Cowork”, supplying an “OTLP endpoint | Your OpenTelemetry collector URL”, an “OTLP protocol | Transport protocol” (http/json or http/protobuf), and “OTLP headers | Authentication headers for your collector”. One practical trap the docs call out: after saving, “Start a new Cowork session — settings are loaded at session start, so existing sessions won’t pick up the new configuration.”

Precondition 3 — desktop app version, where the two cited pages currently diverge. The docs page still states one floor: “OTel monitoring requires Claude desktop app version 1.1.4173 or later.” The help centre, as of 2026-08-03, has split it by session location: monitoring “covers Cowork sessions that run in the cloud (on desktop, web, and mobile) as well as local desktop sessions”, and “Monitoring sessions in the cloud requires Claude Desktop version 1.22209.3 or later, and monitoring local desktop sessions requires Claude Desktop version 1.1.4173 or later.” (receipt R64). Until the pages agree, plan to the stricter reading: an organization on desktop builds at or past 1.1.4173 but before 1.22209.3 should assume its cloud Cowork sessions are not being monitored — the damaging mistake runs the other way (believing coverage exists where the help centre says it does not). This site records that the two pages differ; it does not guess why (the same discipline as the sibling divergence node, Two Anthropic pages disagree on whether the Cowork OpenTelemetry export includes prompt content by default). Either way the condition is per-machine, not org-wide: a staff member on an older build is not covered by your monitoring even though your admin turned it on. One event type carries a higher floor still — the model-response event “Requires Claude desktop app version 1.17377 or later” (docs page).

Precondition 4 — you must run the collector. This is the decisive one. Every field above points outward at infrastructure Anthropic does not supply. The endpoint is “Your OpenTelemetry collector URL”; the docs say “Cowork exports the following events to your OTel collector”; and what you can do with the events afterwards depends entirely on what you have put behind it — “Your choice of logs backend determines the types of analyses you can perform”, with the docs naming log-aggregation systems, columnar stores and observability platforms as the options. Anthropic sends; you must have built something that receives, stores, secures, and retains.

Say this plainly, because a feature-comparison table will not: a small nonprofit with no SIEM, no collector, and no engineer to operate one has no Cowork observability at all via this route. The Compliance API now provides a separate transcript route; see Cowork has Compliance API coverage — verify the session type and exclusions for its current session scope and exclusions. The earlier August coverage disagreement is superseded (receipts R77, R78, R80). Turning this route on is a genuine infrastructure project with an ongoing operator, not a checkbox. If you are being asked to attest that you monitor staff use of Cowork, that attestation has a real cost attached, and you should price it before you make it.

One networking detail worth knowing if you do proceed and your organization restricts outbound traffic: “The OTel exporter runs inside the Cowork VM, so it is subject to the session’s egress rules. If your organization restricts network egress, Cowork automatically adds your collector’s hostname to the session’s egress allowlist. You don’t need to add it at Admin settings > Capabilities > Network egress.”

Before you enable it, read the next node. What the exported events actually contain by default — specifically whether they carry the text of your users’ prompts — is the subject of an unresolved disagreement between two live Anthropic pages: Two Anthropic pages disagree on whether the Cowork OpenTelemetry export includes prompt content by default. For anyone whose prompts might mention a patient, that question decides what your collector becomes.

Source & currency

• Current verification — 2026-09-16 (receipts R81, R82): Both monitoring sources re-fetched. Their content-default and desktop-version-floor differences remain; collector prerequisites are unchanged. The obsolete implication that OpenTelemetry is the sole oversight route was removed.

• Earlier dated entries below are history, not the current verification date.

• Sources: Monitoring — Cowork docs (§Setup, §Events, §Backend considerations, §Security and privacy) and Monitor Claude Cowork activity with OpenTelemetry — Claude Help Center (stamped “Updated today” on the 2026-08-03 fetch).

• Status: CONFIRMED — re-verified 2026-08-03 (receipt R64; original build receipts R42, R43) — every passage this node now quotes verified on the live pages 2026-08-03. Source-pair divergence recorded 2026-08-03 (CG7): the help centre split the desktop-version floor by session location (cloud 1.22209.3 / local 1.1.4173) while the docs page still carries the un-split 1.1.4173 sentence; this node previously stated the un-split floor for both — an error in the permissive direction once the help centre moved (monitoring coverage of cloud sessions would have been overstated for desktop builds between the two floors). Caught by the CG7 source-check leg’s regression sweep, not by a reader of this node. The divergence itself is unstable by nature — either page may change without notice; the CONFIRMED chip re-attests the quotes as of the date shown, and the ⛩ gate may still re-rule the chip class for divergence-carrying nodes. Prior status: CONFIRMED 2026-07-28 (R42, R43). New node at CG6: Cowork observability was not covered anywhere in this curriculum before then.

• ⚑ Compliance-critical: confirm current specifics with your Anthropic contact before relying on this for a compliance decision. This is a teaching aid, not compliance or legal advice.

Related

• Folder & Desktop Access — parent domain
• Cowork has Compliance API coverage — verify the session type and exclusions — current Compliance API session scope and exclusions
• Two Anthropic pages disagree on whether the Cowork OpenTelemetry export includes prompt content by default — what the exported events contain is disputed; read before enabling
• Cowork — what Cowork is, plainly
• Folder Access — connections — the cross-cutting domain’s wired edge-set

Detail

Both statements were verified live on 2026-07-28. They are reproduced here without adjudication, because the graph is not in a position to adjudicate between two current vendor pages — and neither are you, from reading.

What the docs say — metadata only, content is opt-in. From the Cowork monitoring documentation, §Events: “Cowork exports the following events to your OTel collector. By default, events include metadata only. User prompt content, model response text, and tool details are included only when you enable them with the otlpContentCapture setting.” The same page’s §Security and privacy repeats it as a bullet: “User prompt content is included only when you enable userPrompts in otlpContentCapture”, alongside “The tool_input attribute (file paths, URLs, search patterns, and other arguments) is included only when you enable toolDetails in otlpContentCapture.”

What the help centre says — content is included by default. From the help article’s security-and-privacy considerations: “User prompt content is included in events by default. If your organization has policies against logging prompt content to your SIEM, configure filtering or redaction in your collector before routing events downstream.” The same article’s list of what you can monitor leads with “User prompts. The full text of prompts users submit to Cowork.”

Note that the two pages do not merely differ on a default; they differ on who has to act. The docs put the burden on the admin to switch content capture on. The help centre puts the burden on the admin to filter or redact it out, downstream, in their own collector. Follow either one and you get a defensible-sounding process; follow the wrong one for your actual deployment and you are wrong in a direction that matters.

One further observed difference, stated as an observation only: the strings otlpContentCapture and “metadata only” do not appear anywhere in the help-centre article. This site does not offer an explanation for the divergence — Anthropic states no reason for it on either page, and any account of why the pages differ would be our guess, not documentation. What we record is that they differ.

Where the two pages agree — and this part is not in dispute: nothing is exported at all until an admin sets an endpoint. Docs: “Events are only exported when an admin configures the OTLP endpoint.” Help centre: “Events are only exported when an admin configures an OTLP endpoint. No data flows by default.” So the disagreement only bites once you have decided to turn monitoring on. Until then, the safe reading is that there is no export, not that there is a safe export.

Why this is the node to act on. Cowork activity can be exported through OpenTelemetry — if you can run a collector describes the OpenTelemetry route; the Compliance API now offers a separate route with its own scope and exclusions. This node establishes that the route’s most sensitive property is currently undocumented in any single consistent place. If your staff use Cowork on material that could include patient detail (PHI — Protected Health Information), then enabling the export without settling this question means you do not know whether you have just created a second copy of patient information inside a logging system that was almost certainly never scoped, governed, or retention-limited for that purpose.

What to actually do, in order. These six steps are our recommended practice, not Anthropic documentation — the documented fact on this node is the disagreement itself. They are set out here rather than on a separate node because a contradiction a reader cannot act on is just an anxiety.

1. Do not enable the export in production first. Point it at a throwaway collector you control.
2. Send a prompt containing a distinctive marker string — nonsense words, never real patient information.
3. Search the received events for the marker. If it is present, content flowed in that test. If it is absent, first confirm that the expected events actually arrived and inspect filtering, capture settings and session type; a missing marker alone does not prove content is never exported.
4. Repeat the test after any Claude desktop update or admin-settings change, and treat the result as valid only for the version you tested.
5. Ask your Anthropic contact directly, quoting both sentences above, and get the answer for your organization’s plan and app version in writing.
6. Assume the riskier reading until your own test says otherwise. If you cannot run the test, plan as though prompt content is flowing and govern the collector accordingly.

Source & currency

• Current verification — 2026-09-16 (receipts R81, R82): The prompt-content-default disagreement persists. Searches for otlpContentCapture and metadata only remain absent from the help article body; both sources require an admin-configured endpoint. A negative marker test is not treated as proof of no export.

• Earlier dated entries below are history, not the current verification date.

• Sources: Monitoring — Cowork docs (§Events, §Security and privacy) and Monitor Claude Cowork activity with OpenTelemetry — Claude Help Center (§security-and-privacy considerations; the article is stamped only “Updated over a week ago”, with no absolute date).

• Status: STALE-RISK as of 2026-07-28 (receipts R42, R43) — both quoted passages were verified live on this date and were in conflict on this date. The confidence rating is not doubt about what the pages say; it is the recognition that a documented contradiction is by definition unstable, that either page may be corrected at any time without notice, and that the question is too consequential to answer from documentation alone. Confirm with the Anthropic contact, and with your own collector, before relying on either reading.

• ⚑ Compliance-critical: confirm current specifics with your Anthropic contact before relying on this for a compliance decision. This is a teaching aid, not compliance or legal advice.

Related

• Cowork activity can be exported through OpenTelemetry — if you can run a collector — the export itself, and the four preconditions to using it at all
• PHI — Protected Health Information — what counts as patient information, plainly, and why a log store containing it changes your obligations
• Folder & Desktop Access — parent domain
• Cowork — what Cowork is, plainly
• Folder Access — connections — the cross-cutting domain’s wired edge-set