[FEATURE] Add a lightweight "Projects view" to Claude Code, sourced from the local repo/folder (for non-engineer teams)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code's only real unit of sharing is a Git repository, but a fast-growing
share of Code users are non-engineers (writers, ops, PMs, support, domain experts)
who can't or won't operate Git/PR workflows. For them, the folder/Git-first model
is an entry barrier.

There is no lightweight shared-doc space inside Code for the common job of
"organize docs and iterate on drafts with teammates":

• The ONBOARDING.md share link is one-way, uses a single fixed filename, and is

wrapped in an "invite" page — unfit for iterating drafts together.

• claude.ai Projects can't be handed off to Code via URL/path (auth-walled).

So even when GitHub is overkill (meeting notes, SOPs, proposals, spec drafts,
onboarding docs), this cohort is forced into a Git workflow or gives up on Code.
Even at a Fermi-estimate level, these "GitHub-is-overkill" cases likely outnumber
heavy engineering repos for non-engineer users — making this an adoption/funnel
lever, not just a power-user nicety.

Proposed Solution

Add a lightweight "Projects view" in Code that is a VIEW over the local repo/folder,
not a second cloud store:

• Source of truth stays local/Git — no dual source of truth
• Let the user pick which folder/files and which branch/commit the view shows
• Support multiple named views (per purpose), so it's not limited to one target
• Optimize for "browse + edit/iterate with Claude + share", not raw file listing,

so it doesn't merely duplicate GitHub's web UI

A minimal, local-only MVP (no cloud sync) for the "iterate & share docs" job would
already meaningfully lower the barrier to adopting Code.

Alternative Solutions

• GitHub repos + PRs: too heavy for non-engineers; high learning curve.
• ONBOARDING.md share link: one-way snapshot, fixed filename, invite-page framing.
• claude.ai Projects: cloud-only, not reachable from Code via URL/path.

Priority

Low - Nice to have

Feature Category

Other

Use Case Example

Scenario (non-engineer teammate on a small team):

1. Our team keeps working docs — meeting notes, an SOP, a draft proposal — in a

local folder, not a full Git/PR workflow.

1. A non-engineer opens Claude Code, but there is no place to see/organize these

docs as a shared "project"; the only sharing paths are Git or the one-way
ONBOARDING.md link.

1. With this feature, they open a "Projects view" over that folder, browse and

edit the docs with Claude, and share that view with the team.

1. This saves time because the team avoids standing up a GitHub repo + PR process

just to collaborate on a handful of documents — lowering the barrier for
non-engineers to adopt Code at all.

Additional Context

Why this matters (demand): Code's user base is expanding toward non-engineers, for
whom GitHub is overkill for common doc-collaboration jobs (notes, SOPs, proposals,
spec/onboarding drafts). Even at a Fermi-estimate level these cases likely
outnumber heavy engineering repos for this cohort — an adoption/funnel lever, not
just a power-user nicety.

Anticipated objections & mitigations:

• Security (private content/secrets reaching the cloud): keep it local-first; for

any cloud indexing, gate behind confidential computing (TEE), client-side
encryption, VPC, or zero-retention so the guarantee is close to local-only.

• Repo is a moving target: add an explicit branch/commit selector.
• Scale (>200K tokens): curate selected folders/files, not the whole repo.
• Redundancy with GitHub's web UI: differentiate via "browse + edit/iterate with

Claude + share," not raw file listing.

A minimal, local-only MVP (no cloud sync) would already help.