Bug reports and feature requests go to the public o4 issue tracker on GitHub: https://github.com/Open4rena/o4-releases/issues. The fastest way to file one is from inside o4 with /bug or /feedback. Each opens a new issue in your browser with the details already filled in.
Report a bug
Type /bug, followed by a description of what went wrong:
o4 opens the Bug report form on the issue tracker. The form labels the issue bug. o4 fills in:
-
Title: the first line of your text. Titles longer than 80 characters are cut with
….
-
What happened?: your full text.
-
Environment: your o4 version, operating system and CPU architecture, and the model and provider you’re using, for example:
Check the form, fill in Steps to reproduce and What did you expect to happen?, and submit it. o4 doesn’t send anything itself: the issue exists only after you submit it on GitHub, and you can change or remove any field first. You need a GitHub account; GitHub asks you to sign in if you aren’t.
/bug on its own opens the same form with only the environment filled in.
When the browser opens, o4 shows Opened a new GitHub issue in your browser. /bug and /feedback work only inside an o4 session. In print mode (o4 -p), slash commands aren’t run; see Print mode and scripting.
Share an idea or request a feature
Type /feedback, followed by your idea:
o4 opens the Feedback form, which labels the issue enhancement. It fills in the title and Your feedback from your text, and Environment with the same details as /bug.
Long text
A link can only hold so much text. If your text is too long, o4 shortens it to fit and adds (Shortened to fit in a link. Paste the rest here.) at the end. Paste the rest into the form before you submit.
When no browser opens
o4 opens the link with open on macOS, and with xdg-open on Linux when a graphical session is running (DISPLAY or WAYLAND_DISPLAY is set). In an SSH session it doesn’t try, because the browser would open on the remote machine.
When it can’t open a browser, o4 shows the link in the conversation instead and copies it to the clipboard if it can:
Paste the link into a browser on any machine. You can also open the issue tracker directly and choose a form yourself.
/bug and /feedback work even while the model is busy with a task.
What to include
A good report says what you did, what happened, and what you expected. Include:
- The output of
o4 --version, if you file the issue by hand. /bug adds it for you.
- If your terminal or shell might matter, the output of
/doctor, which adds your shell, terminal and working directory. See Show your setup with /doctor.
- The exact command or prompt, and the full error message.
- Relevant lines from
~/.o4/o4.log. For more detail, reproduce the problem after starting o4 with RUST_LOG=debug. See Troubleshooting.
The issue tracker is public. Before you submit, remove API keys, tokens, private code and anything else you don’t want to publish from your text and from any log lines you paste.
