The Dawn CLI now has a built-in bug report slash command. Type /bug inside the active CLI session, follow it with a short description of what just went wrong, and the command files a Dawn feedback report with the current CLI logs and your session context attached automatically.
The point is to keep the report close to the moment the problem occurred. Half the useful detail in a CLI bug report is in the logs from the run that just broke; most of the rest is the session context — which workspace, which agent, which thread you were in — that is fresh in the CLI right now and tends to evaporate by the time someone copies a stack trace into a separate web form.
What /bug Does
The command lives inside the Dawn CLI session itself, alongside /help, /login, and the rest of the slash commands. Typing /bug followed by a short description — /bug workspace switch crashed when I renamed the thread — files a Dawn feedback report from where you are, with whatever context the CLI has about the current session attached automatically. /feedback works as an alias for the same flow.
There is no interactive prompt to fill out. The whole report is the line you type, plus what the CLI gathers itself behind it. If you skip the description entirely and just type /bug, the report still goes through with a placeholder message — but the description is the part the team uses, so it is worth typing the sentence.
The command requires you to be signed in. If you have not run /login yet in the session, the CLI tells you so and stops there rather than filing a report against an unknown identity.
What Gets Attached
When you submit, the CLI builds a small zip — dawn-cli-bug-{timestamp}.zip — and uploads it as the report’s attachment. Two things go inside.
The first is the current CLI log file. Whatever runtime output, errors, and trace data the CLI has written for this session lands in the bundle as a single log. That is usually the most diagnostically valuable piece, because the bug you just hit is almost certainly visible somewhere in that file even if you did not see it scroll past in the foreground.
The second is a small metadata.json describing the session you were in when you ran the command. It records the CLI version, the size and path of the log file, the workspace and agent you were working with (by name and id), the current thread if any (id and title), the shell-tools permission mode the agent was running with, and the working directory the CLI was launched from. None of those are secrets — they are the context a triager would otherwise have to ask for in a follow-up email — and putting them in by default means the first reply from the team is more likely to be an answer than a question.
There is no opt-out flag and no “review before sending” step. The bundle is built and sent on the same line as the /bug command. For users with strict local policies, the practical guidance is to be aware of what you have produced in the session before filing the report — the metadata is benign by construction, and the log contents are whatever has already been written to the terminal.
Where Reports Land
Submitted reports go through the same /feedback API that handles feedback from Dawn Web and from channels. CLI reports show up alongside Dawn Web and channel reports in the team’s feedback inbox, tagged so they can be filtered, with the bundle attached as a regular feedback attachment. There is no separate CLI inbox to forget about and no extra step to wire up — if your team is already triaging Dawn feedback, CLI reports arrive there too.
When the team needs to follow up, the response comes back through the email associated with the Dawn account that submitted the report. The CLI does not start a chat thread or open an issue tracker; it files a feedback record, and the conversation continues over email if there is one to have.
When To Reach For It
/bug is the right channel for things that look like CLI bugs and quality issues. A command that crashed. Output that does not match what the CLI claims it should produce. A behaviour that is plausibly working as intended but is a bad default. A regression between two CLI versions. The kind of report that wants both a sentence from the user and the local context from the failing run, on the same record, without any extra log gathering.
It is not the right tool for production outages or operational escalations — those have their own incident processes the team already runs. It is also not the right place for feature requests or roadmap discussions, which have better homes in the support channels and roadmap conversations the team has set up elsewhere. The line is roughly: if the report has the shape “I tried X, the CLI did Y, that is wrong because Z”, /bug is the right channel; if the report has the shape “the system is broken right now and we need it back” or “we want a feature that does W”, a different one is.
For day-to-day CLI use, the practical effect of having the command is that more issues get reported, and the ones that do arrive come in with enough context to act on. Both of those make the next CLI release a little better than the last one. That is the intent.
Worth Adding To The Internal Troubleshooting Doc
If your team keeps a short internal page on “what to do when a tool misbehaves”, /bug is worth a one-line entry on it:
If the Dawn CLI crashes or misbehaves, type
/bug <short description>in the same session — it files a Dawn feedback report with the current CLI logs and session context attached.
That single line tends to be the difference between issues being reported once with full context, and being reported either three times by three people with no logs or — more commonly — not at all.
Getting Started
Update to the latest Dawn CLI and the command is available alongside the other slash commands. From inside any active CLI session — once you have run /login — type /bug followed by what just went wrong, and the CLI does the rest. The next time something looks broken, the report is one line away, and the team on the other end gets it with the logs and the session context already attached, the way every bug report should arrive but rarely does.