Projects (beta): "Debug access" has no visible effect on the coordinator's tools; list_events reads another project's session with and without it
Status Open
Maintainer reply None cached
Activity 0 comments · opened Oct 14, 2026
What happened
Environment: claude.ai/code (web), Projects beta, 2026-10-14. Pro plan, one account, two projects: A (source) and B (reader). B's coordinator runs Opus 5.5.
Steps:
- In A: Project settings > Debug access, add B, 7 days.
- In B, ask the coordinator to read A's chat/thread, using only its own tools.
- In A, revoke B’s access, restart B’s coordinator, then repeat the list_events call.
Observed:
- B's chat tools are scoped to B. fetch_thread with a thread id from A returns "thread_id: not a valid thread id for this project"; fetch_messages returns an empty list; fetch_project_timeline and list_thread_sessions take no project id.
- list_events (claude-code-remote) accepted a session id from A and returned events while access was granted. After revoking access and restarting B’s coordinator, the same call succeeded again (no error). Re-tested several minutes later: still no error.
- summarize_recent_sessions with that session id returned sessions_skipped: 1, sessions: [] and no reason.
- I cannot rule out revocation propagation delay beyond a few minutes.
Expected: the UI says Debug access lets Claude in another project read this project's chat and threads. I could not find a docs page describing it, or any tool whose description mentions it.
Questions:
- Which tool consumes Debug access?
- Is it required for list_events to read another project's session?
- Why is the session skipped by summarize_recent_sessions?
Note: a project's "read only this project" scope appears to be enforced only by prompt, since list_events reaches sessions of the same account. No cross-account access was observed.
Environment
- Filed from: Report a problem in Claude Code