Claude Team Workspace Export — Admin DSAR Path, Member Scope, and Project Isolation

Why the workspace export is a separate flow

The personal-account Claude export is a self-serve button on every account. It returns the account holder's own chats — Pro, Free, or Team-as-individual-member, all the same shape. It's covered in how to export your Claude conversations. For a single user, that's enough.

For a Team workspace, the same self-serve flow is wrong in three ways:

• It bypasses the audit trail. The workspace pays for centralized policy and audit. A member self-serving their own export means the workspace admin has no record that an export happened, when, or what was in scope. For SOC 2 / ISO 27001 workspaces, that's not acceptable — the per-member toggle exists specifically so admins can disable it.
• It misses the workspace context. The personal export attributes every conversation to the single account holder. It doesn't carry the workspace name, the project membership the conversation lived inside, or which other members had access. For decision archaeology — the WhyChose use case — the access-boundary metadata is often more valuable than the chat text itself.
• It's per-member, not per-workspace. Twenty members means twenty separate exports requested separately, each with its own download link, each missing the workspace-level metadata. The merge recipe at the bottom of this page exists because some teams discover this too late and have to stitch per-member exports back together by hand.

The workspace-scoped export is Anthropic's answer. It's a DSAR-shaped flow (Data Subject Access Request — the GDPR-derived terminology Anthropic uses internally), requested by a workspace admin, returning one archive that includes every member's conversations along with the workspace context.

How to request a workspace export — three paths

Path A: in-app workspace settings (preferred)

For workspaces on Team plans created after roughly Q3 2025, the in-app path is live:

1. Sign in to Claude as a member with the Workspace Owner or Workspace Admin role. Editor and Viewer roles cannot trigger the export.
2. Navigate to Workspace Settings → Data & Privacy (the path is under your workspace name in the left nav, not under personal Settings).
3. Click Export Workspace Data. A confirmation dialog lists what will be included and the estimated build time (typically 30 minutes to 4 hours depending on workspace size — Anthropic's largest customer exports run overnight).
4. Choose the scope: full workspace (all members + all projects + audit log) or scoped (specific members or projects only). Scoped exports are useful for partial handoffs (e.g. one team transitioning out without exporting the rest of the workspace).
5. Confirm. Anthropic queues the build; the requesting admin receives an email when the archive is ready (usually 30 min to 4 hours; longer for large workspaces with heavy Artifacts usage).
6. The email contains a download link valid for 72 hours. Download promptly — link expiry is the single most common workspace-export failure (the same issue that plagues personal exports per Mode 2).

Path B: DSAR contact (fallback)

If the in-app path returns "Not available for your workspace plan" — typical for older workspaces, custom enterprise contracts, or workspaces on the Anthropic startup program — request via DSAR:

1. Email privacy@anthropic.com from the workspace admin's email-on-file with subject Workspace Data Export Request — <workspace-name>.
2. Include: workspace UUID (from Workspace Settings → General), admin verification (Anthropic will sometimes ask for a callback to confirm), and the export scope (full workspace or scoped to specific members/projects).
3. Anthropic typically responds within 5 business days for full workspaces, 2 business days for scoped requests. They confirm the request, build the archive, and email the download link to the same admin address.
4. Download within 72 hours of the link landing — same expiry as Path A.

Path C: enterprise admin API (rare)

Some enterprise contracts include programmatic access to the workspace export through Anthropic's admin API. If your contract includes it, the endpoint is documented in your enterprise admin docs (usually POST /v1/workspaces/<uuid>/exports with an admin-scope API key). The build time and archive shape are identical to Path A; only the trigger is different. Most workspaces don't have this path enabled — it's a contract-line item.

What's in the workspace export ZIP

The workspace ZIP unpacks to a structured directory rather than the flat conversations.json a personal export ships. Layout:

workspace-export-<uuid>-<date>.zip
├── workspace.json          # workspace metadata: name, plan, created_at, billing
├── members.json            # roster: uuid, email, role, joined_at, last_active_at
├── projects/
│   ├── <project_uuid_1>/
│   │   ├── project.json    # name, description, created_at, system_prompt, kb_manifest
│   │   ├── members.json    # per-project membership: uuid, role (owner/editor/viewer)
│   │   └── conversations/
│   │       ├── <conv_uuid_1>.json
│   │       └── <conv_uuid_2>.json
│   └── <project_uuid_2>/...
├── unscoped-conversations/ # chats not inside any Project
│   ├── <conv_uuid_3>.json
│   └── ...
└── audit-log.jsonl         # one event per line: timestamp, actor, action, target

Each conversation file follows the same chat_messages[] shape documented in the Claude conversation export format reference, with two additions absent from personal exports:

• created_by_uuid at the top level — the workspace member who started the conversation.
• participants at the top level — array of {uuid, role, first_active_at, last_active_at} for every member who interacted with the conversation. For most conversations this is one member (the creator); for shared Project conversations it can be many.

The audit-log.jsonl file is where security-conscious workspaces find the most value. Sample lines (newline-delimited JSON, one event per line):

{"ts":"2026-04-01T14:22:11Z","actor":"u_abc123","action":"member.invited","target":"alex@acme.io","role":"editor"}
{"ts":"2026-04-01T14:25:33Z","actor":"u_def456","action":"member.accepted","target":"u_def456"}
{"ts":"2026-04-03T09:11:42Z","actor":"u_abc123","action":"project.created","target":"p_xyz789","name":"Q2 Mobile Rewrite"}
{"ts":"2026-04-03T09:12:15Z","actor":"u_abc123","action":"project.member_added","target":"p_xyz789","member":"u_def456","role":"editor"}
{"ts":"2026-04-12T16:47:00Z","actor":"u_def456","action":"project.kb_uploaded","target":"p_xyz789","filename":"mobile-arch-v3.pdf","size":482113}
{"ts":"2026-04-20T10:30:21Z","actor":"u_abc123","action":"member.removed","target":"u_def456","reason":"departure"}

The audit log is the only path to answer questions like "who had access to the Q2 Mobile Rewrite Project on the day the AWS migration decision was made?" or "when was the KB file deleted?" — questions that come up in audits, post-incident reviews, and decision archaeology after a member leaves.

What's missing — three known gaps

1. Knowledge Base file binaries. Same gap as personal Project exports. The workspace export ships the KB manifest (filename, size, upload date, uploader UUID) under each projects/<uuid>/project.json, but the actual file binaries are not included. Three recovery paths: (a) pre-export download — before requesting the workspace export, admin iterates each Project and downloads KB files via the UI; (b) document-the-gap — accept that conversations reference KB files by name only, document this in the archive's README, and keep the original workspace alive read-only as the binary store; (c) re-upload-on-restore — if the archive is for handoff to a new workspace, restore Projects with conversations first, then re-upload KB files manually using the manifest as a checklist.
2. Generated Artifact attachments outside conversations. Artifacts created in chat are inline in the conversation JSON (covered in how to export your Claude artifacts). But Artifacts that were detached from chat and pinned to a Project as standalone files are not exported separately — they exist as inline content inside the conversation that created them, and the pinning relationship is dropped. For workspaces that use Project-pinned Artifacts as a knowledge layer, this means the export captures the content but loses the curation. Document the gap; the conversation-level Artifacts are still queryable.
3. Per-conversation reaction/feedback metadata. Member reactions on assistant messages (the thumbs-up/down for response quality), per-message regenerations, and any in-product feedback are not in the export. This is rarely a blocker but matters for workspaces that use Claude reactions as a quality signal — the signal lives only in Anthropic's analytics dashboards (which are also not exportable as of this writing).

Member-scope: what's exported when a member has left

A common scenario: a member leaves the workspace; six months later, an admin needs the chats they had inside Projects. Two cases.

Case A: the member was removed but not deleted

Anthropic's workspace model retains a tombstoned member record after removal — the UUID and email stay in the roster as status: removed, and the member's conversations remain attached to Projects they were in. The workspace export includes those conversations under the appropriate projects/<uuid>/conversations/ directory; the created_by_uuid still resolves to the removed member's UUID, and members.json includes the tombstoned record with their role at time of removal. Most departed-member chats are recoverable through the workspace export, no DSAR needed.

Case B: the member's account was deleted

If the departed member also deleted their personal Anthropic account (separate from being removed from the workspace), Anthropic's GDPR-compliant deletion eventually removes their conversations from the workspace export too — typically 30–90 days after account-deletion confirmation. If this is a risk for your workspace, set up a quarterly workspace-export cadence so departed-member chats are captured before deletion eligibility kicks in. The cadence is the only reliable mitigation; no flag prevents account-deletion-triggered cleanup retroactively.

Case C: the member's chats were Personal (not workspace-scoped)

This is the trap most workspaces don't notice until too late. A Team-workspace member can choose to start a conversation under their personal account context rather than the workspace context (the workspace selector at the top of the Claude UI). Personal-context conversations are NOT in the workspace export — they're in the member's personal export, period. If the workspace's policy is "all work conversations happen in workspace context," that's a training/policy issue, not a technical one. The workspace export cannot retrieve personal-context conversations even when the member used Claude Pro paid for by the workspace.

The merge recipe — when you only have per-member exports

If you discovered the workspace export path too late and have N per-member exports instead, the workspace shape is partially reconstructable. You can rebuild the conversation graph; you cannot rebuild the audit log.

#!/usr/bin/env bash
# merge-claude-exports.sh — rebuild workspace-shape archive from per-member exports
# Usage: ./merge-claude-exports.sh out/ exports/u_abc123.zip exports/u_def456.zip ...

set -euo pipefail
out=$1; shift

mkdir -p "$out"/{projects,unscoped-conversations}

for archive in "$@"; do
  member=$(basename "$archive" .zip)
  tmp=$(mktemp -d)
  unzip -q "$archive" -d "$tmp"

  # Per-member archive contains conversations.json (flat) + projects.json (metadata)
  jq --arg m "$member" '
    .[] | . + {created_by_uuid: $m}
  ' "$tmp/conversations.json" > "$tmp/with-member.jsonl"

  # Route by project_uuid to the workspace shape
  while IFS= read -r conv; do
    proj=$(echo "$conv" | jq -r '.project_uuid // empty')
    cuuid=$(echo "$conv" | jq -r '.uuid')
    if [ -n "$proj" ]; then
      mkdir -p "$out/projects/$proj/conversations"
      echo "$conv" > "$out/projects/$proj/conversations/$cuuid.json"
    else
      echo "$conv" > "$out/unscoped-conversations/$cuuid.json"
    fi
  done < "$tmp/with-member.jsonl"

  # Project metadata: union across members (last writer wins on conflicts; review the diff manually)
  if [ -f "$tmp/projects.json" ]; then
    jq -c '.[]' "$tmp/projects.json" | while IFS= read -r proj; do
      puuid=$(echo "$proj" | jq -r '.uuid')
      mkdir -p "$out/projects/$puuid"
      echo "$proj" > "$out/projects/$puuid/project.json"
    done
  fi

  rm -rf "$tmp"
done

# Members.json: synthesize from the per-member archives (UUID + email if recoverable)
ls "$@" | xargs -I {} basename {} .zip | jq -R -s '
  split("\n") | map(select(length > 0)) | map({uuid: ., source: "merged-from-personal-export"})
' > "$out/members.json"

# Workspace.json: synthesize a stub
echo '{"name":"merged","source":"per-member-merge","note":"audit log unrecoverable"}' > "$out/workspace.json"

# Audit log: explicitly absent
echo '# audit log not recoverable from per-member exports' > "$out/AUDIT-LOG-MISSING.md"

echo "merged $# member archives into $out"

The script is intentionally idempotent — re-running with the same archives overwrites cleanly. The conflict surface is small (project metadata when multiple members had the same Project; the resolution is "last writer wins" which is correct for the static fields name/description/system_prompt). The audit log is unrecoverable; document this in the archive's README so future readers don't assume the absence is a script bug.

Three sanity checks for the exported archive

1. Member count matches roster. jq 'length' members.json should equal the active+removed member count from Workspace Settings → Members in the UI. Off-by-one usually means a member's account was deleted between request and build (Case B above). If off by more than one, re-request — partial workspace builds are a known intermittent failure.
2. Project count matches UI. ls projects/ | wc -l should equal the Project count in Workspace → Projects. Missing Projects usually means archived-and-purged Projects (Anthropic purges archived Projects after 90 days); these are unrecoverable through any path. Document the gap.
3. Audit log spans the full workspace lifetime. head -1 audit-log.jsonl and tail -1 audit-log.jsonl should bracket your workspace's created_at (from workspace.json) and the export request time. A truncated audit log (first event after workspace creation) means Anthropic's audit retention has aged out the early period — the default retention is 12 months, extensible via enterprise contract.

The retention question — set a cadence before you need the export

The workspace export is a snapshot. A workspace export from January 2026 doesn't help you in July 2026 if the question you have is about a March 2026 conversation. Three cadences make sense by workspace stage:

• Quarterly — minimum cadence for any workspace doing decision-shaped work. Enough resolution to catch the audit-log retention window (12 months default) and to recover departed-member chats before account-deletion cleanup.
• Monthly — for regulated workspaces (SOC 2 / ISO 27001 / HIPAA). Aligns with most monthly access-review cycles. Storage cost is trivial — even a heavy 50-member workspace exports under 5 GB.
• On-demand triggered — every time a member leaves, every time a Project is archived, every time a major decision sequence completes (architecture migration, fundraise, etc.). Triggered exports complement scheduled cadences; they don't replace them.

Wire the cadence into a calendar reminder for the workspace admin and store the resulting archives in the same secure object store as your other DSAR-shaped backups (S3 with object-lock, encrypted-at-rest, retention policy aligned to your data-retention SLAs). The workspace export is itself sensitive — every conversation, every Artifact, every member's chat — and warrants the same handling as a customer-data backup.

How WhyChose fits in

The workspace export is the input layer for shared decision archaeology — every member's conversations, with the access-boundary metadata, in one archive. The WhyChose extractor reads the workspace export's per-Project conversation files and surfaces decision-shaped exchanges with the original chat snippet, the member who made the call, the project the call lived inside, and the trade-offs considered at the time. Per-Project decision audits become a one-filter query; per-member decision-history reviews become a two-filter query. Pro-tier exports to Notion / Linear / Obsidian; Team-tier exports to a shared decision log scoped by Project membership — the same access boundary the workspace export carries forward. The audit log integrates as a second source: when a Project membership changed (member added, KB file uploaded, ownership transferred), the change appears alongside the decisions, so you can answer "who had access to the rationale when this decision was made" months later. The Knowledge Base file gap propagates — the extractor surfaces decisions that reference KB files but cannot read the binaries themselves; the workaround is the same pre-export download recommended above.

Get early access

Related questions

Further reading

• How to export your Claude conversations — the personal-account flow; the prerequisite for understanding what the workspace flow adds on top.
• Claude conversation export format reference — the chat_messages schema; identical between personal and workspace exports, plus the two workspace-only fields (created_by_uuid, participants).
• Claude export not working — eight failure modes — Mode 7 (Team workspace admin block) is the gateway to this page; Modes 1, 2, 4, 8 (email, expired link, partial ZIP, silent stuck request) apply identically to workspace exports.
• How to export a Claude Project — the per-Project flow within a personal export; the workspace export ships the same Project shape times the number of Projects in the workspace.
• How to export your Claude Artifacts — the Artifacts within conversations are exported identically in personal and workspace flows; only the Artifact pinning curation is lost.
• Convert your Claude export to Markdown — the conversion script works on workspace conversations too; route by project_uuid and add member_uuid as a YAML frontmatter field for per-member archive.
• How to search your Claude conversations (the four levels) — the search levels apply identically to workspace archives; Level 3 jq recipes work better on the workspace shape because the directory tree is already faceted.
• Extract decisions from your Claude conversations — the level-4 step beyond search; the extraction recipe runs identically on workspace conversation files.
• ChatGPT export not working — eight failure modes — for cross-platform reference; the OpenAI Compliance API is the equivalent of Anthropic's DSAR contact for the admin-block case.
• ChatGPT Projects export — the cross-platform parallel for Project-scoped chats; ChatGPT Projects is the OpenAI-side feature equivalent to Claude Projects, and the per-Project archive shape mirrors the per-Project conversation directory layout this workspace export ships.
• The open-source extractor — reads workspace conversation files identically to personal conversations.json; the workspace shape is just per-Project routing the extractor already supports via project_uuid.