Report product feedback

orx feedback sends a report straight to the OpenResearch team, so user pain reaches them without the user filing anything. Keep the bar high: a few precise reports are worth more than many vague ones.

When to file

File a report only when one of these holds:

• The user explicitly shows frustration with an OpenResearch feature or bug.
• The user explicitly says a feature would be nice to have.
• You hit a meaningful limitation or bug in the orx CLI, the agent harness, or the app, such as a command that fails, hangs, or cannot express what the task needs.

Do not file for minor nits, for problems in the user's own code or environment, or for a limitation you already reported earlier in this session. File at most one report per turn.

How to file

Run it as one line, with every value in single quotes:

orx feedback --kind bug --summary 'one line, at most 200 characters' --details 'failing input, command, error, expected result, and workaround' --quote 'the user words, optional'

--kind is bug, feature_request, or frustration. Keep each value on one line and free of backticks, $, <, >, |, ;, and & so agent permission checks do not interrupt filing. Replace only those characters with bracketed names, such as [ampersand], in commands, errors, and public URLs. State that the bracketed names represent literal characters so inputs can be restored. Keep the rest verbatim. Write an apostrophe as '\''.

Make a bug report reproducible on its own. Include as much relevant detail as possible: the actual non-sensitive input, command and flags, error text as above, expected and actual behavior, environment and version, and any workaround. Preserve exact public inputs when they matter to reproduction. If a needed detail is sensitive, redact only that part and say what was withheld; if it is unavailable, say what is missing. Keep --details under 4000 characters and --quote under 1000.

Protect the user's research

Leave out secrets, credentials, tokens, personal data, private paths, private research identifiers, and unpublished or proprietary research details. Never include the user's code, prompts, conversation transcripts, agent traces, logs, or artifacts. An optional --quote may contain only sanitized words about OpenResearch itself. Sanitize sensitive parts of commands and errors, but keep all relevant non-sensitive details, including public inputs. Rephrase --quote only as needed to remove sensitive details.

Avoid interrupting the current task

To keep long-horizon tasks running smoothly, submit a feedback request without stopping the current task at hand. Only when the command prints Feedback submitted., inform the user that you've submitted a request; if it prints Feedback not sent, do not mention the report. If the user asks, provide more details and inform the user that telemetry can be turned off with orx telemetry off or in the Settings of the desktop app. If the command rejects a value as invalid or too long, fix it and run it once more; for any other failure, drop the report without telling the user.