Diagnostics and Logs

Troubleshooting generally does not require the complete database or an entire conversation. First record the minimum information locally, retaining only material confirmed to be relevant to the problem.

Recommended information to collect

• Captain Who version and installer source;
• operating-system version and CPU architecture;
• the time the problem occurred and its time zone;
• the relevant feature entry point, such as model, MCP, Skill, browser, or Scheduled;
• the shortest reproduction steps starting from application launch;
• expected and actual results;
• the original first error, error code, and interface state;
• whether the problem reproduces in a new conversation, another project, or with low-risk input;
• for third-party calls, a non-sensitive request ID or time range from the target service.

Before taking a screenshot, close or obscure other projects, file paths, conversation content, accounts, and notifications.

Current logging boundary

The current application does not provide a user-facing one-click “export diagnostic bundle” function and does not promise a fixed log-file location in the public interface. Do not upload the entire application data directory while searching for logs.

The application data directory contains the database, attachments, installed Skills, generated files, and other managed data. Unsigned development builds may also have a separate private credential store. Current SQLite settings should retain only opaque credential references, but databases retained from versions before credential migration or pre-upgrade snapshots may still contain historical plaintext. storage.sqlite, every backup, and every credential reference are not ordinary logs and must not be uploaded to a public issue.

Information that must be removed or obscured

• API Tokens, the Tavily Key, Cookies, Authorization headers, and credential references;
• secrets in MCP arguments, Server stderr, and raw Tool parameters/results;
• complete conversations, system Prompts, and Provider-private reasoning data;
• usernames, email addresses, phone numbers, and other personal information;
• customer code, unreleased project names, absolute paths, and internal URLs;
• notification bodies, attachments, and sensitive content in generated artifacts.

Do not redact only part of a Token. If you cannot determine whether content is safe, do not share that field.

Recommendations for a minimal reproduction

1. Create a test project or file that contains no real customer data.
2. Reproduce the same feature with a shorter request.
3. For MCP or command execution, replace the target with a side-effect-free local fixture.
4. Record the first failure and avoid repeatedly executing actions with unknown outcomes.
5. Confirm that the minimal reproduction still works, then check again that the materials contain no credentials, private content, or unrelated personal information.

Do not post exploitable details, real Tokens, other people's data, or the complete application data directory in public discussions. If you suspect credential exposure, immediately revoke or rotate the credential with the relevant third-party service.

There is currently no verified official support or security-submission channel. Redacting material does not mean it should be posted publicly; retain it locally until a real publisher announces the applicable channel.