cometchat-troubleshooting
Companion skills:
cometchat-coreis the authoritative source for correct init, login, and provider patterns;cometchat-customizationexplains why drift after customization is expected;cometchat-themingcovers the CSS variable cascade for theme-not-applying symptoms.
Purpose
This skill teaches Claude how to diagnose CometChat integration problems systematically. It explains what each diagnostic tool checks, what the known failure modes are and why they happen, and how to distinguish infrastructure problems (env vars, dashboard config, network) from code problems (wrong init sequence, missing CSS import, drift).
1. Use this skill when
The user has a problem with their CometChat integration. Trigger phrases:
/cometchat troubleshoot/cometchat fix/cometchat fix <symptom>- "chat isn't loading"
- "i'm getting a cometchat error"
- "the chat is broken"
- "blank screen on /chat"
- "401 Unauthorized from cometchat"
- "css-variables not loading"
- "the chat doesn't show messages"
2. Docs MCP contract
The CometChat docs MCP at cometchat-docs is a hard requirement for
this skill. cometchat doctor handles the local diagnostic checks
(integration state, drift, env vars, AST verify rules), but for any
symptom that doesn't match a doctor known-issue code, the MCP is the
canonical source for symptom → cause → fix.
Hard rules:
- Always run
cometchat doctorfirst — its known-issues table covers the common failure modes (env-placeholder, env-missing, drift, init-before-login, no-auth-key-in-source). - For symptoms NOT in doctor's table, query the docs MCP with the exact error message or symptom keywords. Never guess at the cause.
- If the docs MCP is not installed, STOP. Tell the user: "Doctor
didn't recognize this symptom and I need the CometChat docs MCP to
diagnose further. Install it with
claude mcp add --transport http cometchat-docs https://www.cometchat.com/docs/mcpand re-run." - Never blame the user's code if doctor + MCP both pass — the issue is probably infrastructure (network, dashboard config, auth provider).
- Canonical reference URL: https://www.cometchat.com/docs/ui-kit/react/troubleshooting
3. What cometchat doctor actually checks
Understanding what doctor checks helps you interpret its output and know when to look beyond it:
-
Detection — reads
.cometchat/state.jsonto confirm an integration exists. If absent, reportsintegrated: false. -
Env var checks — reads the framework's env file (
.envfor Vite/Astro/React Router,.env.localfor Next.js). Checks eachCOMETCHAT_*variable for:- Presence (key exists in the file)
- Placeholder sentinels (
YOUR_*_HEREstill present = warning)
-
AST verify — parses owned TypeScript files and runs 5 checks:
css_variables_imported_once— counts@cometchat/chat-uikit-react/css-variables.cssimports (must be exactly 1)init_before_login— confirmslogin()call sites appear afterinit()resolves (in a.then()chain or afterawait)render_gated_on_login_resolve— checks thatcreateRoot().render()or JSX is not called at module top level before init completesno_auth_key_in_source— searches string literals for patterns matching auth key format (should be in.env, not source)error_ui_visible_on_failure— confirms that catch handlers set state variables that render visible error UI
-
Drift detection — checksums each file in
state.files_ownedagainst the originally applied template. Reports modified or missing files.
When to go beyond doctor: doctor passes but the app still shows a blank screen → likely SSR, network, or dashboard config. Doctor only checks local code and env files.
4. Steps
Step 1 — Triage: read the project state
npx @cometchat/skills-cli info --json
Three possible outcomes:
info says |
Diagnosis | Next step |
|---|---|---|
integrated: false |
No integration exists | Check for partial state (below). If none, tell user to run /cometchat first and stop. |
integrated: true, drift.has_drift: true |
User edited owned files | Step 2 + flag the drift |
integrated: true, drift.has_drift: false |
Clean integration but something is broken | Step 2 |
If drift is detected, surface the modified file list verbatim. Do not
automatically offer to restore — drift after using
cometchat-customization is expected and correct. Ask the user whether
the changes were intentional before suggesting any restore.
Step 1a — Partial-state recovery (aborted /cometchat runs)
info returning integrated: false doesn't always mean the project is
clean. /cometchat may have been started, errored out, or been
interrupted mid-flow, leaving the project in an inconsistent half-state.
Check these markers in parallel before offering to re-run from scratch:
# All four of these can exist independently after a partial run
test -f .cometchat/config.json && cat .cometchat/config.json
grep -l "COMETCHAT_APP_ID" .env .env.local 2>/dev/null
find src app -name "CometChatProvider.*" -o -name "ChatDrawer.*" 2>/dev/null
grep -rln "@cometchat/chat-uikit-react" src app 2>/dev/null | head -5
Interpret the combination:
| Markers present | Likely state | Recovery |
|---|---|---|
config.json exists, no COMETCHAT_APP_ID in env |
Onboarding was started but app provisioning didn't finish | Re-run the provision step only: npx @cometchat/skills-cli provision setup --app-id <id> --framework <k> (or --name <n> for a new app) |
| env has credentials, no config.json | Credentials were pasted manually but integration wasn't recorded | Run npx @cometchat/skills-cli config init --json to regenerate config.json from detect + env |
| Provider/drawer files written, no CSS import, no provider mount | Integration code was partially written | Ask user whether to finish the integration (route through /cometchat resuming from the plan step) or delete the partial files and start clean |
| CSS import present, no provider wired | CSS-only leftover from an earlier attempt | Delete the stray css-variables.css import or mount the provider — ask user |
All four present but info still says integrated: false |
.cometchat/state.json was never written — the /cometchat flow skipped Step 8 (state record), so every Phase B command (info, status, doctor, verify, uninstall, apply-theme, etc.) thinks the project is un-integrated |
Run state record to rebuild the state.json from what's on disk. Read the list of CometChat files the user has, then: npx @cometchat/skills-cli state record --framework "<fw>" --placement "<type>" --placement-path "<path>" --auth-mode "<mode>" --files-owned "<new-files>" --files-patched "<patched-files-with-patch-id>" --json. After this, info / status / doctor all work correctly. |
Rule: always show the user which markers you found before proposing a recovery path. Never delete config.json, env entries, or source files without explicit approval.
Step 2 — Run verify
npx @cometchat/skills-cli verify --json
This runs the AST checks. The output looks like:
{
"status": "fail",
"checks": {
"css_variables_imported_once": { "status": "fail", "reason": "..." },
"init_before_login": { "status": "pass" },
...
}
}
For each failed check, look up the fix in the table below or via the docs MCP.
Step 3 — Match symptom to known issues
Common doctor issue codes + verify failures and their fixes:
| Issue code / failed check | Likely cause | Fix |
|---|---|---|
env-placeholder |
CometChat env vars still contain YOUR_*_HERE sentinels — user ran integration but never filled in real credentials |
Open the env file doctor names (.env or .env.local) and replace each YOUR_*_HERE with the real value from https://app.cometchat.com → Your App → API & Auth Keys. This is the most common post-init failure. |
env-missing |
A required CometChat env var key isn't in the env file at all | Run cometchat apply --force-overwrite to re-emit the placeholders, then fill them in. |
drift-modified |
Owned files have been edited since apply | If the user used cometchat-customization or hand-edited intentionally, this is expected — not a bug. cometchat info flags it because the checksum changed. Only offer cometchat apply --force if the drift is accidental. Ask before restoring — force-apply destroys intentional customizations. |
drift-missing |
An owned file was deleted | Run cometchat apply --force to recreate the missing file. |
css_variables_imported_once (count=0) |
The css-variables.css import was removed | Re-add @import url("@cometchat/chat-uikit-react/css-variables.css"); to the top of src/index.css (or the per-framework target). For Astro, it goes inside the .tsx file, not the global CSS. |
css_variables_imported_once (count>1) |
Imported in multiple places | Remove the duplicate. Keep only the one in the canonical location. |
init_before_login |
Code calls CometChatUIKit.login before CometChatUIKit.init resolves |
In the provider pattern (Next.js, Astro, React Router SSR): use await init(settings) followed by await login() sequentially inside useEffect. In the entry-file pattern (Vite/CRA): chain init(settings).then(() => login()).then(() => mount()). See cometchat-core section 6. |
render_gated_on_login_resolve |
createRoot(...).render is called at top level, not inside a mount() function |
Wrap render in mount() and call it only after login() resolves. For React island frameworks, gate render with if (!user) return null. |
no_auth_key_in_source |
Auth Key hardcoded in a source file | Move it to .env and reference via the framework's env prefix (import.meta.env.VITE_COMETCHAT_AUTH_KEY, process.env.NEXT_PUBLIC_COMETCHAT_AUTH_KEY, etc.). |
error_ui_visible_on_failure |
No visible error state rendered on init/login failure | In the component that calls init()/login(), add a catch handler that sets an error state, then render: <div style={{ color: "red", padding: 16 }}>CometChat Error: {error}</div>. The full pattern is in cometchat-core section 6 (CometChatProvider). |
For symptoms not in this table, proceed to Step 4.
Step 4 — Framework-specific patterns
Many issues are framework-specific. Check against these common patterns:
| Framework | Symptom | Likely cause | Fix |
|---|---|---|---|
| Next.js | Blank screen / hydration mismatch | CometChat components rendered on the server | Add "use client" to the file, or use dynamic(() => import(...), { ssr: false }). See cometchat-core section 5. |
| Astro | Theme not applying | CSS override in a global .css file instead of inside the React island |
Move --cometchat-* overrides inside src/cometchat/ChatApp.tsx. See cometchat-theming section 1. |
| Astro | Components not rendering | Missing client:only="react" directive |
Add client:only="react" to the island component in the .astro file. |
| React Router v7 | window is not defined at build |
CometChat imported in a module that runs on the server | Wrap in React.lazy + Suspense with a ClientOnly guard. See cometchat-react-router-patterns section 3. |
| Vite / CRA | CSS variables not taking effect | Override block appears BEFORE the @import of css-variables.css |
Reorder: the @import must come first, overrides must follow. |
| Any | 401 Unauthorized | Wrong or expired auth key in .env |
Check .env for YOUR_AUTH_KEY_HERE. Replace with real value from app.cometchat.com → API & Auth Keys. |
| Any | CometChat is not initialized |
Component renders before init() resolves |
Use the provider pattern from cometchat-core section 6, or add an isReady gate before rendering CometChat components. |
| Any (React 19) | Cannot update a component (ForwardRef) while rendering a different component |
Known React 19 warning from CometChat UI Kit internals (closePopover calls setState during render). Not a bug in your code. |
Ignore — this is a cosmetic warning from inside the UI Kit's minified bundle. The UI works correctly. Will be fixed in a future UI Kit release. Do NOT try to patch this in user code. |
Step 5 — Symptom-driven lookup via the docs MCP
If the user has reported a specific symptom that isn't covered by verify checks or the framework table, query the CometChat docs MCP:
Use the cometchat-docs MCP to search for "<symptom keywords>"
Common symptom searches:
| Symptom | MCP search query |
|---|---|
| Blank screen at /chat | "blank screen ssr nextjs" or "blank screen react-router" |
| 401 Unauthorized | "401 unauthorized authentication" |
| Chat doesn't load | "chat not loading init login" |
| Build error | "" |
| CORS error | "cors origin allowed" |
| Mixed user/group error | "user group same component" |
| Theme not applying | "theming css variables override" |
The docs MCP returns the canonical fix. Apply it as a targeted patch.
Step 6 — Propose the fix
Show the user:
- What's broken (verify output, drift report, or symptom)
- The likely cause (from the table or docs MCP)
- The exact fix (file path + content change)
- Whether to:
- Patch the specific issue — targeted edit to the broken file. Preferred for most issues.
- Restore from the registry —
cometchat apply --forcerewrites all owned files back to their template state. Safe only if the user hasn't customized them. Ask first. - Re-run the integration cleanly —
cometchat uninstall --forcefollowed by/cometchat. Wipes state.json and starts over. Last resort.
For dashboard/network/auth issues, the fix is on the user's side
(CometChat dashboard, .env values, network connectivity) — cometchat doctor surfaces the issue and the fix verbatim. Don't try to "fix"
infrastructure issues from the CLI.
Step 7 — Verify the fix
After any fix is applied, re-run:
npx @cometchat/skills-cli verify --json
Confirm status: "pass". If anything is still failing, repeat from Step 2.
Hard rules
- Never apply a fix without showing the user what will change first.
- Never invent error causes — query the docs MCP if you don't know.
- Never blame the user's code if the verify checks are passing — the issue is probably in the docs MCP territory (network, auth, dashboard config).
- For drift, default to showing the drift and asking if it was intentional, not auto-restoring. Drift after customization is expected.
- Always use
npx @cometchat/skills-cli.