Claude Couldn’t Load Your Projects: What to Check

If Claude couldn’t load your projects, check service status, confirm your account, and try opening the project from the full Projects page. A loading error tells you the request failed; it does not establish that the project or its files were deleted.

Avoid creating replacement projects until you know what is inaccessible. A separate work record in fenbs can preserve the next step while you investigate, but it cannot restore a Claude project or bypass its access controls.

What should you do before changing anything?

1. Save any unsent text in a safe place before refreshing the page or signing out.
2. Record the exact error, the time and time zone, and whether it affects every project or just one.
3. Confirm that you are signed in to the account and organization where the project belongs.
4. Open the full Projects page and, if you have it, try the project’s saved link.
5. Check Claude’s service status, then test one different browser session if there is no incident explaining the failure.

Keep the first test narrow. If ordinary chats work but the Projects page fails, say that in your notes. If only one shared project fails, that is a different pattern from a blank account. These observations help you choose the next check without guessing at an internal cause.

Could a service incident explain the failure?

Open Claude’s official status page↗ (opens in a new tab) and read the affected service and incident description. A problem with the API or Console does not automatically explain a problem in the chat app. Match the report to the part of Claude you are using.

If an incident matches, preserve your notes and retry after the reported recovery. Repeatedly clearing local data will not repair a service incident. If no incident matches, continue testing; a status page is useful evidence, but it cannot diagnose your individual account or browser.

Do not infer a project failure from an unrelated usage warning. Anthropic’s error-message guide↗ (opens in a new tab) distinguishes usage limits, login problems, capacity constraints, and service incidents. Record the message you actually see instead of replacing it with a more familiar explanation.

How can you isolate a browser or sign-in problem?

After saving unsent work, refresh once and try the same project in another browser session signed in to the same account. Compare the account and organization carefully. A successful test under a different account would not tell you whether your original session is working.

For login problems, Anthropic recommends checking browser extensions, VPN use, and cache or cookies in its troubleshooting guide. Treat these as tests when signing in is part of the failure, rather than a guaranteed cure for every Projects error. Follow your organization’s rules before changing a managed network or browser setup.

• Works in another browser: compare extensions and site data in the failing browser.
• Fails in both browsers for the same account: investigate account access and service behavior next.
• Works for a colleague with their own authorized access: compare membership and organization, without exchanging credentials.
• Fails only on one permitted network: ask your IT contact whether a network control needs review.

Change one condition at a time and note the result. If you clear site data, expect to sign in again and preserve anything unsaved first. Do not delete project content, disable organization protections, or share sign-in details as troubleshooting shortcuts.

What if the project list loads but yours is missing?

Move from loading checks to locating the project. Anthropic’s project-management guide↗ (opens in a new tab) describes Your projects, Organization, and Shared with you lists. Check the lists available in your account and the archived-project area before concluding that an entry is gone.

If a saved project link opens, compare that result with the list. If the link fails too, record whether the page says access was refused, the project was not found, or it simply could not load. Those outcomes are useful to support; none gives you permission to work around the owner’s access choices.

For the separate problem of a project disappearing from view, see Claude projects disappeared. Once access works, a consistent naming and archiving routine from organizing Claude Projects can make the next search easier.

Should the project owner check your access?

For a shared project, ask its owner to verify that your current account still has the intended access. Use the project-sharing guide for that separate check. Have each person test with their own account; comparing authorized access is enough.

Tell the owner whether you changed organizations or began using another email address. If access was deliberately removed, the owner must decide whether to restore it. Recreating a project from someone else’s private material is not an appropriate substitute for that decision.

While you wait, record the work as blocked on project access. Preserve the known next action without treating an unavailable reference as reviewed. The fenbs workflow keeps that distinction in task progress and Where we left off, so a later assistant can see why work paused.

What should you send to support?

If the problem persists across suitable sessions and the owner confirms access, use Anthropic’s official support route↗ (opens in a new tab). Include enough information to reproduce the failure, without sending the contents of a confidential project unless support specifically needs them through an appropriate channel.

• The exact error text and a screenshot with unrelated private details removed.
• When it started, your time zone, and whether it happens consistently.
• Whether all projects fail, one project fails, or only the list fails.
• The affected browser or app version and the results of your comparison tests.
• Whether the project is yours or shared, and whether the owner confirmed access.

Ask support to investigate availability or access, rather than asserting that the project was deleted. Keep new observations in the same support conversation. If you need to resume elsewhere, use only source material you still have permission to access and label any reconstruction as incomplete.

How to do this with fenbs

1. Create a free account, free for one person with no credit card, and add the work project.
2. Add the interrupted task. Record the last completed step, the access blocker, and any check that remains unfinished.
3. Add confirmed project facts as AI context notes and record the decisions a person approved in Decisions and rules. Keep sensitive project files in their appropriate source system.
4. After access returns, follow Integrations to connect a supported assistant over MCP, a standard way for an AI app to use outside tools.
5. Ask the assistant to read the project context, verify the source material is available, and save updated progress before stopping.

If your only need is to reopen a Claude project, Claude’s own controls and support are the right place to work. fenbs fits when tasks and decisions need to survive interruptions or changes of assistant. The AI memory hub covers related continuity questions.

When the project loads again, check one important file and one pending task before announcing that work has resumed. Update your restart note with what you actually verified. Access returning and the underlying work being complete are separate milestones.