Submit Chatgpt Feedback

Report ChatGPT or Codex Feedback

Route the report from the exact affected task, preserve privacy, keep submission non-interrupting, and keep private diagnostic upload separate from public publication.

Continuous improvement

Improve this skill as part of using it. Whenever use, debugging, investigation, or user feedback produces a durable verified finding that would help future executions, update the skill during the same task, without waiting for a separate request. Update its instructions, scripts, tests, or references as appropriate, retest the affected behavior, and validate the skill before finishing.

After every modification, reassess progressive disclosure. SKILL.md stays a concise operating contract and router: universal safeguards stay here, and conditional detail moves into a directly linked reference whenever that removes irrelevant context without hiding a safeguard or fragmenting the skill.

Preserve reusable knowledge only. Do not record guesses, secrets, credentials, duplicate guidance, or transient runtime state.

Authorization boundary

1. Establish whether the user asked to draft, submit private in-product feedback, or publish to GitHub. These are three different permissions.
2. Treat "file", "report", and "submit" as authorization for one private product-feedback submission. A request to draft or prepare is not authorization to send.
3. Never publish a GitHub issue or comment unless the user explicitly authorizes public posting. Private feedback authorization never implies public publication.
4. Treat session logs, browser logs, screenshots, codex doctor output, and public evidence as separate disclosure decisions. State exactly what will be included before sending.

Non-interruption boundary

• Never raise, focus, navigate, click, type into, or open a ChatGPT/Codex feedback dialog unless the user explicitly requests interactive UI handling in the current turn.
• Never use Help-menu, Accessibility, AppleScript, computer-use, screenshot-driven, or coordinate-based automation to prepare or submit feedback.
• Prefer an exposed purpose-built feedback tool. When none is available, use the local Codex App Server feedback/upload route documented in references/background-upload.md.
• /feedback is the documented interactive user route, not a background agent command. If background submission is unavailable or fails, leave the sanitized report prepared, say plainly that it was not submitted, and offer the exact /feedback handoff without opening it.

Route by product and surface

• For Codex App, CLI, IDE extension, Web, integrations, or other Codex components, read references/reporting-routes.md. Use a purpose-built feedback tool or the background app-server route for authorized private submissions. Reserve /feedback for an explicitly requested interactive handoff.
• For generic ChatGPT feedback, use the native ChatGPT feedback or support route. Do not post it to openai/codex merely because Codex performed the filing.
• For a usage question or support request rather than a reproducible bug, use the appropriate support or discussion route instead of forcing it into a bug form.

Core workflow

1. Find the existing task whose conversation best supports the report. Verify its visible title, exact task id, reproduction details, and whether an earlier attempt was drafted, privately uploaded, or publicly posted. Do not create a new task when a relevant one exists.
2. Gather the fields the current surface-specific form requires: product version/build, platform, setup, actual result, reproducible steps, expected result, and useful additional context. For performance or suspected memory-retention reports, read references/evidence-quality.md.
3. Before proposing a public issue, search existing openai/codex issues. Prefer a reaction on a matching issue; add a sanitized comment only when the new evidence materially helps diagnosis. Avoid duplicates.
4. Review every report and attachment for prompts, task ids, private paths, repository names, credentials, personal data, and raw logs. Prefer concise text to screenshots. Use codex doctor --json only after reviewing its redacted output.
5. State the private payload before sending: report text, affected task metadata, log inclusion, browser data, screenshots, and extra files. Every diagnostic and attachment field stays off unless the user explicitly authorizes it. --dry-run prints the exact payload without connecting.
6. Confirm which client the report belongs to. When more than one first-party client is active, such as the desktop app and the IDE extension together, the helper refuses to guess: name the binary for the affected surface with --cli, because the reported surface and version follow that choice. See references/background-upload.md.
7. Submit private Codex feedback with no UI through a purpose-built feedback tool or the background helper. When compatibility is uncertain after a client update, run the helper's non-submitting --check first. Record the exact identifier the response returns; do not invent, rename, or embellish it. A response without that identifier is a schema mismatch, not a success.
8. Only when public posting is explicitly authorized, resolve the current openai/codex issue form at execution time, then react, comment, or create the issue as appropriate. Never hardcode a numbered issue-template URL.
9. Delete the temporary report file. Because the background route never navigates or focuses the app, no task or window restoration is needed.

Evidence language

• Separate observation from root-cause inference. A restart clearing growth is evidence about the process coalition, not proof of the leaking component.
• Do not call one large snapshot a confirmed memory leak. Prefer "suspected unbounded growth" or "resource retention" until repeated growth and failure to reclaim are measured.
• Distinguish summed descendant RSS from physical footprint, because shared pages can be counted more than once.
• State untested gaps, missing reproductions, and attachment boundaries explicitly.

Definition of done

• The exact source task, product surface, authorization scope, and report text are verified.
• Private feedback is either left prepared or accepted by a non-UI route, matching the user's authorization.
• Success is claimed only from a successful feedback/upload response, and the returned identifier is recorded verbatim.
• For explicitly authorized public filing, duplicate handling and the resulting reaction, comment, or issue URL are recorded.
• Included diagnostics and the privacy review are stated, temporary private text is deleted, and the user's UI was never interrupted.

Weekly public updates

On first use in a task, or the next use after a week in a long task, follow references/public-updates.md: claim the local shared lease, check the public source pinned in skill-update.json, and explain any available update. Ask the user if they want it first; install only after they explicitly agree, through the appropriate safe route. Silence or continued use is not approval. This is agent-triggered, not a background service. Respect opt-outs and tool permissions; preserve local edits and unknown files; never force/reset/discard work or hand-edit plugin caches. Keep dates and locks outside the skill. Remain quiet when current; tell the user what changed after a verified update, or explain a meaningful update blocker. Updating files never authorizes the skill's domain actions.