ShellCanvas / docs

Appearance

Report a reproducible issue ​

A good report lets someone else see what you saw. That means a sequence they can follow, the exact wording you got, and enough about your setup to tell whether the problem is yours or everyone's — with nothing in it you would regret publishing.

Prerequisites ​

Before writing anything, confirm the problem is not already a known boundary:

  • Check Compatibility and known limitations. A missing feature listed there is not a defect.
  • Check the section-specific page — connection, files or apps — and run its checks.
  • Confirm you are on the current release. Fixed problems reappear in reports more often than new ones do.
  • Reproduce it once more, deliberately, noting each step as you take it.

Steps ​

1. Reduce it. Find the shortest sequence that still fails. A report that says "open Files on a folder with a broken symlink, press Delete" is actionable; "it crashes sometimes" is not.

2. Record the environment. ShellCanvas version, Windows version, and — for anything involving a connection — the server's SSH implementation and version, and the remote operating system. For extension problems, the extension's id and version.

3. Quote the error exactly. Copy the visible wording rather than paraphrasing it. Distinct messages map to distinct code paths, and a paraphrase loses that.

4. State expected versus actual. Both, explicitly. What you believed should happen is often where the real disagreement is.

5. Attach the diagnostics report for adapter problems. App Manager → Connection adapters → Connection diagnostics → Copy report produces a timeline that is redacted by design — no configuration values, arguments, paths, method names, payloads or process output. It is safe to attach as-is, and it is the single most useful artifact for a connection that will not start.

6. Redact before you post. Remove or replace host names and addresses, usernames, remote paths, file content, tokens and anything about your network's shape. Never include passwords, private keys or passphrases — no support request needs them, and anyone asking for them is not helping you. Screenshots leak more than people expect; check the window title, the path bar and the terminal scrollback before attaching one.

7. File it. Open an issue in the ShellCanvas repository. For a suspected security vulnerability, do not open a public issue — follow the private process in the repository's SECURITY.md.

Expected result ​

A report that someone can act on without a round trip: they can follow the steps, see whether it reproduces, and tell from the environment whether it is specific to your setup. Reports that get resolved quickly nearly always share the same shape — small reproduction, exact wording, honest description of what was already tried.

If the behaviour turns out to be a documented boundary, that is still useful: it means the documentation did not reach you where you needed it, which is its own defect.

Limitations ​

ShellCanvas is an early prototype maintained in the open. There is no support contract, no response-time commitment and no private support channel for ordinary issues; the public tracker is the route. Reports about unimplemented features will be closed as such, and reports that require your specific hardware or a device nobody else has may not be reproducible at all — in that case, the most valuable thing you can contribute is a precise description plus a willingness to test a change.

Never include a secret in an issue in order to make it reproducible. If a problem genuinely cannot be described without one, say so in the report and leave the secret out.

ShellCanvas documentation

© 2026 ShellCanvas