Morphism Clerk Dns Auth Troubleshooting
Morphism Clerk Dns Auth Troubleshooting
Source: morphism-clerk-dns-auth-troubleshooting.md (ingested 2026-03-28)
I used the simpler path: the Vercel-backed live wrapper at run-live-auth-billing-from-vercel.ps1. The production live auth test failed before login, and the root cause is now concrete: clerk.morphism.systems is NXDOMAIN, so Clerk JS never loads and /sign-in renders blank. I confirmed that with Playwright and DNS checks (Resolve-DnsName and nslookup), and recorded it in backlog.md, DEPLOYMENT_STATUS.md, and session-log.md. Docs checks still pass.
The next step is not Stripe. It is Clerk/DNS. Either restore the Clerk custom domain in DNS/Clerk, or switch production envs to a working Clerk frontend API and redeploy. After that, rerun:
Set-Location 'C:\Users\mesha\Desktop\GitHub\github.com\morphism-systems\morphism' .\apps\morphism\scripts\run-live-auth-billing-from-vercel.ps1 -Mode status -VercelEnvironment production
› Not sure why you are stuck at these steps. Why do you think that is?
• Because the repo was healthy enough to suggest the flow should work, but the first real external dependency was broken.
The pattern was:
- Local code/tests/builds passed.
- Vercel envs existed.
- Billing routes and Playwright contracts were valid.
- But the actual production auth surface depended on clerk.morphism.systems, and that host does not resolve.
So this was not really “stuck on Stripe.” It was a hidden auth infrastructure failure upstream of Stripe. Until sign-in works, checkout and portal are unreachable.
Why it felt sticky:
- The docs and env inventory implied Clerk was live.
- The app returned 200 on /sign-in, so at a glance it looked healthy.
- The failure only became obvious when I ran a real browser flow and inspected network errors.
- That kind of issue sits outside normal unit/build validation, so you only catch it with real E2E or direct DNS/network inspection.
So my diagnosis is:
- There was config drift between “documented/live” and “actually reachable.”
- The production publishable key points Clerk at a dead frontend API host.
- That made the sign-in page blank, which blocked everything after it.
The good news is that this is now narrowed down very precisely. The next move is one of:
- restore DNS/custom-domain setup for clerk.morphism.systems, or
- switch production Clerk keys/config to a working default Clerk frontend API and redeploy.
After that, the rest of the flow should be straightforward to re-run.
› Give me a step-by-step details for claude chrome (here in chat and in a way to avoid it complaining aobut not changing settings/etc.)
• Searched site:clerk.com docs custom domain Frontend API CNAME Cloudflare Clerk domains
─ Worked for 1m 43s ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
• Use Claude in Chrome as a navigator and inspector first, not as the final clicker for security-sensitive settings. That usually avoids the “I can’t change settings” loop.
How To Run It
- Open Chrome and log in yourself to:
- Clerk Dashboard
- Cloudflare
- Vercel
- Use one task at a time. Do not ask Claude to fix Clerk, DNS, and Vercel in one prompt.
- If Claude hesitates on settings, use this fallback line:
Use read-only inspection first. If a change is needed, prepare the exact form and stop before the final Save/Confirm/Deploy click so I can approve it myself.
Prompt 1: Clerk Inspection Paste this into Claude in the Clerk tab:
You are operating inside my own authenticated dashboard session.
Task: inspect only first. Do not save or change anything yet.
Go to the Morphism production Clerk instance, then open the Domains page.
I need you to report exactly:
- The current production Frontend API domain
- Whether the custom domain is active, pending, failed, or missing
- The exact DNS records Clerk requires for this domain
- Whether SSL/certificates are issued and healthy
- Whether there is a fallback/default Clerk domain visible
- Whether the production publishable key is tied to this Frontend API domain
Important:
- Do not change settings yet
- Do not summarize vaguely
- Copy the exact domain names and statuses shown in the UI
- If a fix is needed, open the relevant form and stop before the final confirmation button
What you want Claude to find:
- clerk.morphism.systems
- domain status
- exact required DNS target(s)
- whether Clerk thinks the domain is verified
Prompt 2: Cloudflare DNS Comparison Then switch to Cloudflare and paste this:
You are operating inside my own authenticated dashboard session.
Task: inspect first, then stage if needed.
Open Cloudflare DNS for morphism.systems and search for any records related to clerk.
Compare the existing DNS records exactly against the Clerk DNS requirements I already collected.
I need you to tell me:
- Which Clerk-related DNS records currently exist
- Which required records are missing or incorrect
- Whether any record is proxied when it should be DNS-only
- The exact edit needed for each incorrect record
If a DNS change is required:
- Open the edit/create form
- Fill in the exact values from Clerk
- Stop before the final Save click so I can approve it
Important rule:
- Do not guess the DNS target. Use exactly what Clerk shows.
- If Cloudflare has a proxy toggle, do not invent the setting. Match Clerk’s recommended setup.
Prompt 3: Quick Production Verification After DNS is fixed or confirmed, open a fresh tab on the live site and paste:
Open https://morphism.systems/sign-in and inspect the rendered page.
Tell me:
- Whether an email or identifier field appears
- Whether a password field appears
- Whether the page is blank
- Whether there are visible error messages
- Any failed network requests related to Clerk or auth assets
Do not sign in yet. Just verify whether the auth UI now renders correctly.
Success condition:
- You should see a real sign-in form, not a blank page.
Prompt 4: Vercel Env Check If DNS Looks Fine But Auth Still Fails If Claude says the DNS is correct but /sign-in is still blank, go to Vercel and paste:
You are operating inside my own authenticated dashboard session.
Task: inspect only first.
Open the Vercel project for morphism, then go to Settings -> Environment Variables.
Check the Production values for:
- NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY
- CLERK_SECRET_KEY
Important:
- Do not reveal the secret key value
- Do not paste any full secret into chat
- Tell me only whether the publishable key appears to correspond to the same Clerk production Frontend API domain shown in the Clerk Domains page
If the publishable key looks wrong or stale:
- Stage the correct replacement using the current Clerk production publishable key
- Stop before the final Save click so I can approve it
What matters here:
- the production NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY must match the working Clerk production frontend API/domain
- if it still encodes the dead clerk.morphism.systems host, auth will stay broken
Prompt 5: Redeploy If DNS or Vercel envs changed, use this in Vercel:
Open the latest production deployment for the morphism project and prepare a redeploy of the current build.
Stop before the final confirmation click and tell me exactly what will be redeployed.
Then click confirm yourself.
Prompt 6: Final Live Check Open https://morphism.systems/sign-in again and verify that:
- The sign-in form renders
- The Clerk assets load successfully
- There is no blank-page auth failure
If the form renders, stop and tell me the auth surface is healthy.
Then come back here and I can run:
- status
- checkout
- portal
with the local Vercel-backed wrapper.
What To Avoid
- Do not ask Claude to “fix everything.”
- Do not ask Claude to expose full keys or secrets.
- Do not let Claude invent DNS values.
- Do not do Stripe work before /sign-in is visibly healthy.
Why This Is The Right Order The real blocker is Clerk, not Stripe:
- /sign-in is blank
- clerk.morphism.systems does not resolve
- until that is fixed, checkout and portal cannot be meaningfully tested
Official Clerk references:
- Frontend API and publishable keys: https://clerk.com/docs/guides/how-clerk-works/overview
- Changing production domain: https://clerk.com/docs/deployments/changing-domains
- Account Portal / hosted auth pages: https://clerk.com/docs/authentication/using-clerk-hosted-uis
If you want, I can also write the exact “single-message” Claude prompt for just the Clerk tab first.
› yes give me the separate messages (3?)
• Yes. Paste these one at a time into Claude in Chrome.
Use them in this order:
- Clerk
- Cloudflare
- Vercel + live verify
Do not combine them.
Message 1: Clerk
You are operating inside my own authenticated browser session.
Task: inspect only first. Do not save or change anything yet.
Open the Morphism production Clerk instance and go to the Domains / Frontend API area.
I need the exact current state for production auth. Report precisely:
- The production Frontend API domain
- Whether the custom domain
clerk.morphism.systemsis active, pending, failed, missing, or disabled - The exact DNS records Clerk requires for this domain
- Whether SSL / certificate issuance is healthy
- Whether a fallback default Clerk domain is available
- Whether the current production publishable key is tied to the same Frontend API domain
Important instructions:
- Do not make changes yet
- Do not summarize vaguely
- Copy the exact domain names, statuses, and DNS targets shown in the UI
- If a fix is needed, open the relevant form and stop before the final Save / Confirm click
- I will perform the final confirmation myself
Message 2: Cloudflare
You are operating inside my own authenticated browser session.
Task: compare and stage only. Do not finalize changes.
Open Cloudflare DNS for morphism.systems and search for any records related to Clerk.
Use the exact Clerk requirements I already collected from the Clerk dashboard. Do not guess values.
I need you to tell me:
- Which Clerk-related DNS records currently exist
- Which required records are missing
- Which existing records are incorrect
- Whether any record is proxied when it should be DNS-only
- The exact DNS edits needed to make Clerk auth work
If changes are required:
- Open the create/edit form
- Fill in the exact values from Clerk
- Stop before the final Save click
- I will approve and click Save myself
Do not invent DNS targets. Match Clerk exactly.
Message 3: Vercel + Live Verify
You are operating inside my own authenticated browser session.
Task: inspect production env alignment, then verify the live auth surface. Do not reveal secrets and do not finalize env edits without stopping first.
Open the Vercel project for Morphism and go to Settings -> Environment Variables.
Check the Production values for:
- NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY
- CLERK_SECRET_KEY
Rules:
- Do not display or expose the full secret key
- Do not paste any secret value
- Only tell me whether the production publishable key appears aligned with the currently correct Clerk production Frontend API domain
If the production publishable key looks stale or tied to the wrong Clerk domain:
- Stage the correct replacement
- Stop before the final Save click
- I will confirm it myself
After that, if any Clerk DNS or Vercel env change was made, prepare a production redeploy and stop before the final confirmation click.
After redeploy, open: https://morphism.systems/sign-in
Then tell me:
- Whether the sign-in form renders
- Whether an email/identifier field is visible
- Whether a password field is visible
- Whether the page is blank
- Whether there are failed Clerk asset requests
- Whether production auth now appears healthy
After you run those, send me only:
- the Clerk domain status
- whether DNS was missing/wrong
- whether Vercel prod key looked stale
- whether /sign-in now renders a real form
• Use this as Message 4 after Clerk is fixed and /sign-in renders normally.
You are operating inside my own authenticated browser session.
Task: verify the real production billing flow step by step. Do not change pricing settings or dashboard configuration. Only perform the user flow and report exactly what happens.
First, open: https://morphism.systems/sign-in
Sign in with the test account I will provide inside the browser session.
Then verify this sequence:
- Confirm sign-in succeeds
- Confirm whether I must create or select an organization
- Open
/dashboard/settings/billing - Tell me whether billing state loads correctly
- Tell me whether the visible primary action is:
- Upgrade Plan
- Manage Billing
- something else
If the org is on a free plan:
- click the upgrade flow
- verify whether it redirects to Stripe Checkout
- stop once Stripe Checkout is visibly loaded
- do not complete payment unless I explicitly tell you to continue
If the org already has an active subscription:
- click Manage Billing
- verify whether it redirects to the Stripe Billing Portal
- stop once the Stripe Billing Portal is visibly loaded
I need a precise report:
- final URL
- whether redirect succeeded
- whether Stripe page visibly loaded
- any error text
- whether the billing flow appears healthy
Important:
- Do not change Stripe settings
- Do not create new products or prices
- Do not edit billing configuration
- Do not expose any secrets
- Stop before any irreversible payment confirmation unless I explicitly approve it
If you want to split that into two safer variants, use these:
4A: Checkout only
You are operating inside my own authenticated browser session.
Sign in to morphism.systems, go to /dashboard/billing, and verify the free-plan upgrade path only.
I need you to:
- confirm sign-in works
- confirm billing page loads
- click the upgrade action
- verify whether it redirects to Stripe Checkout
- stop as soon as Stripe Checkout visibly loads
Report:
- final URL
- whether Checkout loaded
- any visible error
- whether this path is healthy
4B: Portal only
You are operating inside my own authenticated browser session.
Sign in to morphism.systems, go to /dashboard/settings/billing, and verify the billing portal path only.
I need you to:
- confirm sign-in works
- confirm billing page loads
- click Manage Billing
- verify whether it redirects to the Stripe Billing Portal
- stop as soon as the Billing Portal visibly loads
Report:
- final URL
- whether Billing Portal loaded
- any visible error
- whether this path is healthy
Once you have that result, send me:
- checkout works or checkout failed
- portal works or portal failed
- final URL
- visible error text, if any
Then I can decide whether we even need the automated wrapper again.