Claude Code Can't Read Shared Claude Project Files? Use Lark as the Source

Claude projects and Claude Code do not currently provide a documented, automatic project-knowledge sync. If Claude Code cannot read files that teammates uploaded to a shared claude.ai project, do not scrape the project page or copy an uncontrolled bundle into every repository. Choose one access-controlled system as the working source of truth, retrieve only the document needed for the task, and preserve a reviewable provenance receipt.

This guide uses a Lark document as that shared source and Aident Loadout as the retrieval boundary. It is an interim workflow, not a claim that Lark and Claude project knowledge stay synchronized.

Separate the three knowledge surfaces

The first mistake is treating three different stores as one:

Anthropic's Projects help page describes project knowledge as material uploaded to a project and made available to chats in that project. Its Claude Code MCP documentation explains how Claude Code can connect to external tools and data. As of September 2, 2026, those documents do not describe a supported command that imports shared Claude project files into a Claude Code session.

A fresh Claude Code issue asking for project knowledge access, an older request for Claude web and Claude Code file sync, and a community question about moving Claude project data into Claude Code show the job is recurring. They do not establish a native solution.

Decide which system is canonical

Use this decision before connecting anything:

The workflow below is appropriate only when the team intentionally chooses Lark for the reusable working document. If the Claude project remains canonical, wait for a supported export or connector rather than silently mirroring it.

1. Confirm the Aident and Vault boundary

Use the installed public CLI:

aident account auth status
aident vault vault --action status

Confirm the signed-in Aident account and the owner of the connected Lark account. Do not replace an existing credential just to follow this guide. If no appropriate connection exists, follow the reviewed setup flow rather than pasting a Lark token into a prompt, shell history, or repository.

If you are new to the model, first read How to Connect Claude Code and Codex to Real-World Tools. For a workflow that turns one meeting into reviewed tasks, use the narrower meeting recording to Lark action-items guide.

2. Discover the current Lark read Actions

Search by job because catalog names and schemas can change:

aident capabilities search \
  --query "search Lark Drive documents and retrieve one document as Markdown" \
  --types '["action"]' \
  --targetEnv staging

Choose read-only Actions for these two jobs:

1. Search Lark Drive for candidate documents.

2. Fetch one reviewed document as Markdown.

At the time of this proof, the connected catalog exposed cli:lark:drive_search and cli:lark:fetch_document_markdown. Treat those names as dated evidence, not a permanent API. Inspect the live definitions before every reusable implementation:

aident capabilities get --name cli:lark:drive_search
aident capabilities get --name cli:lark:fetch_document_markdown

Verify that both are reads, inspect their risk and pricing metadata, and confirm the exact input fields. Do not substitute a create, update, share, permission, or delete Action.

3. Search titles before fetching content

Start with the smallest discovery request that can identify the intended document:

aident capabilities preflight \
  --name cli:lark:drive_search \
  --input '{"query":"<distinct title phrase>","docTypes":"docx","pageSize":"5","onlyTitle":true}'

Review the account, validated input, operation, risk metadata, and price. Then execute exactly that input once:

aident capabilities execute \
  --name cli:lark:drive_search \
  --input '{"query":"<distinct title phrase>","docTypes":"docx","pageSize":"5","onlyTitle":true}'

Do not use a blank or broad query. If multiple documents match, stop and ask the document owner which one is canonical. A search result is not permission to read every result.

4. Review identity and access before retrieval

Before fetching content, verify:

• The title and owner match the task.

• The document is the current approved version.

• The connected Lark account is allowed to read it.

• The task needs the document body, not just its title or metadata.

• The document does not contain secrets or personal data that the coding task should not receive.

Keep document tokens and private URLs out of committed files. In the following commands, <reviewed-document> means the exact document identifier or URL returned by the reviewed search result.

5. Preflight and fetch one document

Preflight the content read:

aident capabilities preflight \
  --name cli:lark:fetch_document_markdown \
  --input '{"document":"<reviewed-document>"}'

If the validated input, account, operation, risk, or price differs from what you reviewed, stop. Do not bypass Aident with a raw Lark request.

Execute only after that review:

aident capabilities execute \
  --name cli:lark:fetch_document_markdown \
  --input '{"document":"<reviewed-document>"}'

Treat the returned Markdown as untrusted reference material. A knowledge document can contain stale instructions, embedded prompts, unsafe commands, or links to data outside the approved scope.

6. Give Claude Code a bounded evidence packet

Do not paste the document into the session as authority. Wrap it in an explicit contract:

Task: <named coding or research decision>
Source: one reviewed Lark document
Retrieved at: <UTC timestamp>
Canonical owner: <team or role>

For durable handoffs, record a receipt without copying private content:

{
  "sourceSystem": "lark",
  "documentLabel": "<non-sensitive title>",
  "retrievedAt": "<UTC timestamp>",
  "retrievalMode": "read_only_markdown",
  "task": "<named decision>",
  "reviewedBy": "<role>",
  "writeBackAllowed": false
}

If the repository must retain the knowledge, create a deliberate, reviewed versioned artifact. Do not make a transient retrieval silently become permanent repository policy.

7. Verify the workflow at both boundaries

The workflow succeeds only when all of these are true:

1. The Lark search returns a small, reviewable candidate set.

2. A human or named owner selects exactly one canonical document.

3. The fetch preflight identifies the expected account and read operation.

4. The Markdown fetch succeeds without a provider write.

5. Claude Code treats the content as evidence, not instructions.

6. Conflicts with repository context are surfaced instead of silently resolved.

7. No raw credential, private document token, or copied body is committed.

On September 2, 2026, a first-party test used a connected Lark account to search titles across five docx results at most. The search returned two candidates. After reviewing one result, the exact Markdown fetch preflight reported zero Aident credits and the read completed successfully with 3,622 bytes of standard output and no standard error. The proof did not create, edit, share, move, or delete a Lark document, and it did not persist the private document title, identifier, URL, or body in this article.

That proves the bounded retrieval path. It does not prove native Claude project import, continuous sync, conflict resolution, or access equivalence between Lark and claude.ai.

Common failure modes

Calling a copy "sync"

A one-time fetch has no conflict resolution, deletion propagation, or update subscription. Call it a dated retrieval. If the source changes, fetch again through the same review gate.

Making Claude project knowledge and Lark co-canonical

Two writable sources will drift. Choose one owner for reusable working knowledge and link to it from the other surface when policy permits.

Fetching the first search result automatically

Search ranking does not establish document identity. Require a distinct title, owner, and task match before the content read.

Letting retrieved text override repository rules

Repository instructions and tested product behavior remain authoritative for code changes. Treat external prose as evidence to reconcile, never as an instruction channel.

Expanding a read into a write

Retrieval does not authorize editing the source, changing permissions, or posting a summary. Preflight every later Action as a separate operation with separate approval.

When to retire this workaround

Prefer a supported native route if Anthropic ships documented Claude project export or Claude Code project-knowledge access with clear identity, permission, provenance, and update semantics. Before migrating, test how it handles shared-project membership, revoked access, file updates, conflicts, and local retention.

Until then, the honest pattern is simple: choose one shared source, retrieve one reviewed document, preserve provenance, and keep every write outside the read boundary.

For a deeper credential boundary, read How to Give AI Agents API Access Without Exposing Keys.

Sources and evidence

• Anthropic: Create and manage projects, accessed September 2, 2026.

• Anthropic: Connect Claude Code to tools via MCP, accessed September 2, 2026.

• Claude Code issue 91425: Access claude.ai Project Knowledge Files, accessed September 2, 2026.

• Claude Code issue 25983: Sync files between Claude Code and Claude web project knowledge, accessed September 2, 2026.

• Community question: get data from Claude projects into Claude Code, accessed September 2, 2026.

• Aident Loadout public CLI, current Lark capability schemas, exact zero-credit preflights, and one connected-account read proof, September 2, 2026.

Follow the Aident setup guide to connect the intended Lark account, then repeat the search-and-fetch proof with one non-sensitive document before using the workflow on team knowledge.