Getting support
A real person reads every message. The fastest way to a useful answer is to send the few details that turn a guess into a diagnosis.
Two ways to reach us
From inside the app
This is the better option when something failed. The composer attaches the failure log from the step that broke, so the reply can address the actual error instead of asking you to reproduce it. You will find it where the failure happened: on a connection that did not work, at the end of a setup wizard, and in the pairing flow.
By email
Anything else, including questions that are not about a specific failure:
lisa@onepilotapp.comWrite in whatever language you are comfortable with. If you already opened a thread, reply on it rather than starting a new one so the history stays together.
What to include
You do not need all of this. The more of it you send, the more likely the first reply is the answer rather than a question.
| Detail | Why it matters |
|---|---|
| What you expected, and what happened | Separates a bug from a feature working as designed but confusingly. |
| The exact error text | Paste it rather than describing it. Onepilot shows raw errors on tap and they are always copyable. |
| CLI version and host OS | Roughly a third of reports are fixed by an upgrade alone. |
| Where the host lives | A VPS, a home machine behind a router, a container, or a work laptop. This changes how your phone reaches it. |
| What you already tried | Stops the reply from suggesting it again. |
A useful paste
Run this on the host and include the output:
onepilot --version
uname -a
onepilot serve
onepilot relay status
tail -n 40 ~/.onepilot/bridge.logOn Windows, replace uname -a with systeminfo and read the log from your user folder instead.
What never to send
- Private keys, or the contents of your
~/.ssh/directory. - SSH passwords or passphrases.
- LLM provider API keys, or the tokens for Telegram, Discord, and Slack.
- An unused pairing code. Anyone who sees one can log in until it is used. If you have posted one anywhere, clear it with
onepilot pair --clean.
The log files are written with this in mind and do not contain your credentials or your terminal scrollback, so bridge.log is safe to share. If you are ever unsure about a line, redact it and send the rest.
Reporting a security issue
Email the same address with security in the subject line, and please do not open it publicly first. Include what you found and how to reproduce it. You will get an acknowledgement that a human has read it, and we will keep you updated as it is addressed.
Feature requests and feedback
Same address. Requests that describe the problem you ran into tend to go further than ones that describe a solution, because the underlying need often has a simpler answer than the feature that first comes to mind.