Troubleshooting

Common issues and how to resolve them.

Chat is not responsive

If you send a message in the chat and nothing happens, no response, no loading indicator, the Claude Code CLI may be waiting for a confirmation prompt in the terminal.

How to fix it

1. Switch to the Terminal view (click the "Terminal" tab above the chat, or press Cmd+Shift+T)
2. Check if the CLI is prompting you to:
   • Trust the project folder
   • Confirm permission bypass
   • Accept any other confirmation
3. Accept the prompt
4. Switch back to Chat

The session should resume normally.

Why this happens

Claude Code has a workspace trust system that requires confirmation the first time you open a new project folder. PandaOS passes --dangerously-skip-permissions by default to skip these prompts, but in some cases the CLI may still ask, for example with older sessions or custom permission modes.

This is a one-time issue per project folder. Once you've accepted the trust prompt, it won't appear again for that folder.

Reporting a crash

If PandaOS quits unexpectedly, three kinds of diagnostic artifacts may be on disk. All are local-only, nothing is uploaded automatically.

Daily log filenames use local time; crash artifact filenames use UTC. When correlating the two, be aware of the timezone offset (e.g. a crash at 23:30 local time on Apr 20 produces main-20260420.log and crash-20260421T...-*.json side by side).

Daily log file

The main process mirrors its logs to a daily file for the last 7 days. Attach the file for the day of the crash.

• macOS: ~/Library/Logs/PandaOS/main-YYYYMMDD.log
• Windows: %APPDATA%\PandaOS\logs\main-YYYYMMDD.log
• Linux: ~/.config/PandaOS/logs/main-YYYYMMDD.log

Each file contains plain-text log lines prefixed by level and tag. Lifecycle markers ([lifecycle] {"kind":"startup", ...} and [lifecycle] {"kind":"clean-exit", ...}) make it possible to tell whether the previous session exited cleanly. A missing clean-exit marker before the next startup marker means the previous run crashed.

Crash artifacts

When the JS side of the main process throws an uncaught error, rejects an unhandled promise, or a renderer / child process dies, a structured JSON file is written alongside the daily log:

crash-YYYYMMDDTHHMMSS-<kind>.json

where <kind> is one of uncaughtException, unhandledRejection, render-process-gone, or child-process-gone. Each file contains the error, stack trace, app / Electron / Node versions, memory snapshot, and the last 200 log entries leading up to the crash.

Native minidumps (rare)

For native-side aborts (SIGSEGV, V8 FATAL), Electron writes a minidump to a separate directory. These are binary files, attach them as-is if you can find them; they're only useful to developers.

• macOS: ~/Library/Application Support/PandaOS/Crashpad/completed/
• Windows: %APPDATA%\PandaOS\Crashpad\reports\
• Linux: ~/.config/PandaOS/Crashpad/completed/

What to send

When filing a bug, a GitHub issue, or a support email: attach the daily log for the day of the crash and any crash-*.json files written around the time of the crash. The /api/crashes endpoint (reachable by the renderer when the bridge server is up) also lists all crash artifacts with their paths for convenience.