[FEATURE] Sanctioned, user-directed read access to your own claude.ai Projects for Claude Code and assistive agents
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, agents built on the Claude Agent SDK, and any other tool a user runs have no supported way to read the user's own claude.ai Projects and chats. The Messages API is stateless, and Claude Code can't see claude.ai. For Team and Enterprise members it's worse: only the Primary Owner can export data, the export covers the whole organization, and the download link expires after 24 hours. An individual member has no way to take their own work with them.
The Consumer Terms bar access through "automated or non-human means." The only exceptions are API keys and access Anthropic "explicitly permits." That clause draws no line between a scraper crawling at scale and a person directing their own tool to open one item they asked for. It also says nothing about assistive technology.
That gap lands hardest on users with disabilities. With VoiceOver on, a blind user mostly interacts with the screen reader, not the page. The screen reader reads the accessibility tree, jumps between landmarks and acts on elements for the user. An AI agent that opens a Project on a user's request does the same kind of work, just with more steps planned for them. AI is quickly being recognized as assistive technology: Meta has committed to give free AI glasses to every blind veteran in the U.S., describing them as tools for reading documents and completing everyday tasks. Under the current terms, a blind user asking an agent to read their own Project, or a user with a motor or executive-function disability delegating that task, is using "non-human means."
Proposed Solution
An official, read-only path for a user's own tools to access that user's Projects and chats, through an API or MCP server, with:
- OAuth scopes granted per Project by the user
- Read-only access: no sending, editing or deleting
- On-demand, per-item requests, with rate limits that rule out bulk crawling
- An access log visible to the user and org admins
- An admin on/off switch for Team and Enterprise orgs
As part of the same change, update the terms to explicitly permit user-directed access through this path, including by assistive technology and AI agents acting on a user's request. The narrow, scoped design is what makes that permission safe to grant.
Alternative Solutions
- Org data export: owner-only, whole-org, manual, and the link expires in 24 hours. Members can't export their own work.
- Connectors: Claude can push summaries to a wiki or Drive, which helps, but only for what Claude chooses to write. The source chats stay locked in.
- Bookmarklets, browser extensions and cookie-based MCP bridges: they work today, but they call internal endpoints the terms don't allow, and third-party extensions put users' and their clients' data in a vendor's hands.
- Copying and pasting by hand: the current reality, and the least accessible option of all for users who rely on assistive technology.
Priority
High - Significant impact on productivity
Feature Category
MCP server integration
Use Case Example
I'm a tech lead at a small web agency. My team plans client work together in Claude Projects, then I hand scoped follow-up work to a local agent. Today I copy context out by hand. With scoped read access, I'd say "pull the latest decisions from this Project," and the agent would fetch that one Project, read-only, because I asked. One request, one item, on my behalf.
The same path serves assistive use directly. For example, a blind developer working through a long Project with a screen reader could ask an agent to "summarize the decisions in this Project and list the open questions," instead of navigating hundreds of messages one landmark at a time.
Additional Context
Much of my client work is making sites meet WCAG. This is the same pattern accessibility has dealt with before. CAPTCHAs were the original "prove you're human" gate, and accessibility forced them to change: WCAG Success Criterion 1.1.1 requires alternatives so a CAPTCHA doesn't lock out assistive technology users. Blanket "no automated access" rules are headed for the same collision now that AI agents act as assistive technology.
There's legal context worth weighing too. The DOJ's position is that ADA Title III covers websites of businesses open to the public, even though no Title III web rule exists yet. Enforcement happens through private lawsuits, and federal website accessibility filings rose 27% in 2025, according to Seyfarth Shaw. Title III also requires businesses to make reasonable changes to policies when needed for a disabled person's access, and a no-automation clause is a policy. As AI agents are increasingly treated as assistive technology, a clause with no assistive carve-out is the kind of policy those requests will target.
This isn't a request to permit scraping or bulk export. It's a request for the narrowest possible sanctioned path: a person directing their own tool, one request at a time, to read their own work.
If this affects you, add a 👍 to this issue and share your use case in the comments, especially if you rely on assistive technology. Specific, real-world examples are what move requests like this.
Related: #52641 (shared history between claude.ai and Claude Code).
Meta announcement: https://www.prnewswire.com/news-releases/blind-veterans-cross-the-army-ten-miler-finish-line-despite-heavy-rain-with-support-of-meta-ai-glasses-and-lighthouse-guild-302907656.html