A useful Scylla issue report should make the failure reproducible without including credentials, private project data, or unnecessary account information.
Use the support/contact channel provided by the Scylla Workbench site or the support path supplied by your organization.
Before reporting
Check Troubleshooting first.
For many issues, identify which layer is failing:
Scylla application
Scylla Account / Team
Agent Provider
Workspace / Knowledge Scope
Policy
Keyring
Connection
MCP
Memory
external service
If you can narrow the issue to one layer, support can usually move much faster.
Include these details
A good report contains:
Scylla version
Include the version shown by the installed application.
Windows version
Include the Windows edition/build if relevant to installation, terminal, filesystem, WebView2, or process behavior.
What you were doing
Describe the operation in one or two sentences.
For example:
In
cxl-scylla, I asked the Codex provider to run Git status. The provider was connected, but Scylla returned an operation failure before Git output appeared.
What you expected
State the expected behavior.
What happened instead
Include the visible error text or state.
Reproduction steps
Give the shortest repeatable sequence you know.
Example:
- Launch Scylla.
- Open project X.
- Choose provider Y.
- Run operation Z.
- Error appears.
Scope
If the issue concerns files, include the safe project/folder path or a sanitized substitute.
Do not attach unrelated directories.
Policy
If the operation is authority-related, include the effective verdict:
ALLOW
ASK
BLOCK
and whether Team-managed Policy applies.
Provider/runtime
Include the provider name and relevant runtime/version when visible.
Connection type
For SSH/database/MCP issues, say what kind of connection is involved without including its secret.
Examples:
PostgreSQL over direct TLS
MySQL through SSH bastion
HTTP MCP with OAuth
Git HTTPS
Screenshots
Screenshots are useful for:
- UI layout problems;
- stale status;
- account/seat state;
- Policy display;
- Memory status;
- provider state;
- visible non-secret errors.
Crop or redact anything sensitive before sending.
Logs and diagnostics
If Scylla exposes a Copy Diagnostics or similar action for the affected provider/service, prefer that over copying raw application directories.
Review diagnostics before sending them.
Do not send an entire home directory, project repository, Keyring store, or browser profile.
Never include secrets
Do not put any of the following in a support ticket:
passwords
API keys
OAuth tokens
session cookies/tokens
SSH private keys
database passwords
raw .env files
full secret-bearing connection strings
billing-card data
Keyring exports
If a bug appears to require a real credential to reproduce, create a disposable test credential or coordinate a safer reproduction path instead.
Security-sensitive issues
If you believe Scylla exposed a credential, bypassed an authority boundary, or performed an operation that should have been blocked:
- Stop reproducing against production systems.
- Revoke/rotate any credential that may have been exposed.
- Preserve the safe diagnostic evidence you already have.
- Report the issue through the designated Scylla support/security contact path.
- Clearly mark the report as security-sensitive.
Do not post live credentials to a public issue tracker.
UI issue reports
For visual problems, include:
- screenshot;
- window size/resolution;
- Windows display scaling;
- which Scylla panel/modal;
- whether the issue changes after resize;
- whether it occurs every launch.
Provider issue reports
Include:
- provider name;
- provider runtime/adapter version if visible;
- authentication state;
- whether a new chat reproduces it;
- whether another provider works in the same project;
- sanitized error text.
Do not include the provider's authentication token.
Memory issue reports
Include:
- active project;
- whether the source is local or Team Memory;
- visible service state;
- whether results are empty, unavailable, provisioning, or wrong-project;
- the query/topic used, if non-sensitive.
Wrong-project Memory is especially important to report because project identity should remain exact.
Team/account issue reports
Include:
- organization name if safe to share;
- your role;
- seat-assignment state;
- subscription state shown in the console;
- whether desktop sign-in succeeded;
- whether the problem affects one member or the whole Team.
Do not send account passwords or browser session data.
A strong issue template
### Summary
One sentence describing the problem.
### Environment
- Scylla:
- Windows:
- Provider/runtime:
- Project:
### Expected
What should have happened.
### Actual
What happened instead.
### Steps
1.
2.
3.
### Policy / scope
Relevant Workspace/Knowledge scope and ALLOW/ASK/BLOCK state.
### Error
Sanitized error text.
### Reproducibility
Always / intermittent / once.
### Attachments
Screenshots or safe diagnostics only.