[BUG] Desktop 1.20186: "Projects" (Cowork/epitaxy) redirects to Claude Code — new "Code" entitlement gate blocks the surface on Bedrock/3p

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On Claude Desktop 1.20186.x (3p / Bedrock), clicking the "Projects" tab
in the Cowork home does not open the project-creation form (name + description). Instead it briefly
routes to /projects, immediately replaceStates to /epitaxy, and lands on the Claude Code session
view.

Downgrading the app binary only to 1.19367.0 — same account, same on-disk config, same machine —
restores the Projects form. So the regression is in the app version, not in local config or account state.

The 1.20186 web bundle added an entitlement guard on the /epitaxy route (absent from 1.19367) that
evaluates the "Code" account entitlement and, when it resolves to no_entitlement, redirects out of the
Projects surface. On a 3p/Bedrock deployment this entitlement is not provisioned, so Projects is
unreachable — even though Claude Code itself is available and running in the same build
(launch: supported, ccdPlugins: supported, CCD sessions work).

What Should Happen?

Clicking "Projects" should open the project-creation form (as it does in 1.19367.0). The Projects/epitaxy
surface should either not be gated behind the Claude Code account entitlement on 3p/custom-provider
deployments, or there should be a documented way to provision that entitlement for a Bedrock/3p org.

Error Messages/Logs

``shell
# No 5xx / network error at click time — the redirect is a deliberate client-side guard.

# Navigation trace (history.pushState/replaceState logger in DevTools):
[NAV] ACTUAL       -> /task/new
[NAV] pushState    -> /projects
[NAV] replaceState -> /epitaxy      # then Claude Code renders

# Guard found ONLY in the 1.20186 web bundle (ion-dist/assets/v1/*.js):
messageForLogging: "Claude Code unavailable, redirected away from /epitaxy."
errorContext.tags: { source: "epitaxy_entitlement_redirect", code: "no_entitlement" }
UI message: "Claude Code isn't available for this account."
# unsupportedCode in Set(["upgrade_required","no_entitlement"]) -> i.replace(b) (eject)

# grep over both bundles:
#   "redirected away from /epitaxy"   -> absent in 1.19367.0, present in 1.20186.1
#   "isn't available for this account"-> absent in 1.19367.0, present in 1.20186.1

Steps to Reproduce

1. Use a 3p / custom-provider (Bedrock) Desktop build on 1.20186.x.
2. Open the Cowork home (New task / Projects / Artifacts / Scheduled entries).
3. Click "Projects".
4. Observe: routes to /projects, then redirects to /epitaxy and shows Claude Code —
   the project-creation form (name + description) never appears.
5. Downgrade the app binary to 1.19367.0 (same account/config/machine) and repeat step 3:
   the Projects form opens correctly.

Ruled out during investigation:
- Not local config: 1.19367 works against the current (post-1.20186) config unchanged.
- Not the epitaxyMcpApps GrowthBook flag: it reports "unavailable" in EVERY captured version,
  including 1.19367.0 where Projects worked. Full capability diff between the two versions
  (same account, same day) is identical except an unrelated `launch` entry.
- Only differing factor is the app version; only relevant code delta is the new
  epitaxy_entitlement_redirect guard.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.19367.0 (Desktop app)

Claude Code Version

1.20186.1 (Claude Desktop app; 3p deploymentMode, Bedrock)

Platform

AWS Bedrock

Operating System

macOS

Terminal/Shell

Other

Additional Information

• This is the Claude Desktop app (Cowork), not the CLI — the bug form is CLI-oriented, so a few fields

are best-fit approximations.

• Build: deploymentMode: "3p", Bedrock provider; macOS arm64.
• Claude Code is fully available in this build (CCD sessions run; launch/ccdPlugins = supported) — the

guard's "Claude Code isn't available" message is misleading; the failing check is the account-level
"Code" entitlement specific to the epitaxy surface, not CCD availability.

Questions:

1. Is gating the Projects/epitaxy surface behind the "Code" account entitlement intentional in 1.20186?
2. If yes, how should a 3p/Bedrock org provision this entitlement so unsupportedCode is no longer

no_entitlement?

1. If no, can the guard treat 3p/custom-provider deployments as entitled (consistent with 1.19367)?