Get help with a problem

3 minute read · Settings

A useful report tells us what you tried, what happened and what should have happened. Start with one reproducible problem so the result is easy to check.

• Give the next person a path to the problem
• Share only what is needed
• Write a report someone can reproduce
• Preserve evidence and protect private data
• Distinguish the failing service

Give the next person a path to the problem#

Search the guides for the affected feature first. If it still fails, open Support or Feedback and describe the sequence: which view, which action, the error and the expected result. Include your app version and operating system when requested.

For example: “In Small Stories Preview, search for morning. The article exists in the full list but the search returns no matches. Empty search restores all three.” This is more actionable than “search is broken.”

Share only what is needed#

Select screenshots and attachments deliberately. Remove tokens, passwords, recovery codes, personal records and private project text that is unrelated to the failure. Sending the form is your explicit action; automatic telemetry is a separate preference and service.

For a saved-work or migration problem, preserve the current profile and recovery files. Do not clear storage before a diagnosis, especially when the failure concerns an encryption key.

Next: account recovery, Vault recovery, updates.

Write a report someone can reproduce#

Use the support form with the task you were doing, exact steps, expected result and actual result. Include app version, platform and the visible stage of failure. A concise example is:

In Small Stories, I edited an article title and pressed Save. The success message appeared, but after reloading Preview the old title returned. It also remains old in the API response. This happened on a local test record.

For a visual issue, attach a screenshot that includes the affected control and enough surrounding layout to understand it. For a provider failure, include the provider/model and sanitized error. For sync, describe the devices, pending/conflict state and whether the Vault was unlocked.

Preserve evidence and protect private data#

Do not clear the profile, remove encryption keys or recreate projects before reporting a possible data-loss issue. Preserve recoverable local files and note the last successful operation. A new empty profile can hide the problem while making recovery harder.

Attachments are voluntary. Remove passwords, tokens, recovery links, customer records and unnecessary personal paths. A log may contain secrets even when the visible error does not. Send only the relevant excerpt and explain what you redacted. Automated telemetry is separate from an explicitly submitted support report and follows its own preferences.

Distinguish the failing service#

For a Vortex sign-in problem, include the verification step and visible account error. Provider eligibility/quota belongs to the connected coding-agent account. A database query runs on the selected database; a local preview depends on the project's processes. Naming the failing layer helps support avoid asking you to change unrelated settings.

After a proposed fix, repeat the same small reproduction and check the saved result after restart/reload where appropriate. Report what changed and what remains broken. A green fixture test or a downloaded update alone is not proof that your real workflow is repaired.