Reporting Issues

Bugs and feature requests go to Issues, filed through the issue forms. Security problems go to a private advisory, never a public issue.

Before you file

• Search the existing issues for the same problem.
• Check Troubleshooting for a known fix.
• Read the FAQ if the question is about platform support or scope.

File a bug report

Use the bug report form. Include these details. Reports without them get a needs-info label.

• The OpenBox version, from Settings, then About.
• Your operating system and version. On Linux, include the distribution and desktop.
• Your Python version, if you run from source.
• The diagnostic report, from Settings, then Library Audit.
• Steps that reproduce the problem.

To test from a fresh data folder, give OpenBox its own data directory:

OPENBOX_DATA_DIR=/tmp/openbox-repro python3 web_app.py --no-browser

File a feature request

Use the feature request form. To discuss a direction first, start in Ideas. For a substantial change, open an issue before you open a pull request.

How triage works

1. A report that cannot be reproduced stays open for 14 days. Then it closes, with an invitation to reopen it with more detail.
2. Each report gets a severity label.

Severity	Meaning
critical	Data loss, or a launch failure that affects everyone
major	A broken feature for many users
minor	An edge case
polish	A cosmetic problem

Other labels are bug, enhancement, documentation, reproduced, confirmed, wontfix, and good first issue. The response targets are on the Community page.

Report a security problem

Do not open a public issue for a vulnerability. Report it privately through a security advisory. Fixes land on master. Older release lines are not backported, so upgrade to the latest release. SECURITY.md covers scope and supported versions.