Skip to content
CommandChain CommandChain CommandChain Docs

Get help

Try common issues first: most reports turn out to be one of the entries there, and it will be faster than waiting for us. When it is not, here is where to go.

Where to reach us

Section titled “Where to reach us”

Beta support: reply to your invitation

Section titled “Beta support: reply to your invitation”

Reply to the email that carried your beta invitation. During the closed beta that mailbox is the support channel, it is read by the people who build the product, and replying keeps your account details attached to the thread so we are not asking who you are.

If you have deleted it, ask whoever invited you to send another. There is no separate ticket system to sign up for.

Runner and installer problems: the public issue tracker

Section titled “Runner and installer problems: the public issue tracker”

The runner ships from a public release mirror, and its issue tracker is open to anyone with a GitHub account:

https://github.com/commandchain-ai/commandchain-runner-dist/issues

Use it for anything about the installer or the runner binary: a failed checksum, an install that stops on your platform, a doctor result you did not expect, a service that will not stay up. It is public, so do not paste credentials, tokens, or private repository contents into an issue. Anything account-specific belongs in email instead.

What to include

Section titled “What to include”

A report with these four things usually gets a fix in the first reply. Without them, the first reply is a question.

  1. Versions

    Section titled “Versions”
    Terminal window
    commandchain-runner version               # the runner, on the machine it runs on

    Your workspace address identifies the platform build, so send that too.

  2. The doctor output

    Section titled “The doctor output”

    doctor answers whether the machine can contain a coding agent. It prints no secrets.

    Terminal window
    commandchain-runner doctor                # can this machine contain a coding agent

  3. What you did, and what happened

    Section titled “What you did, and what happened”

    The steps that reproduce it, what you expected, and what you got instead. An exact error message beats a description of one: they carry stable error keys such as no_runner_available, trial_credits_exhausted, or NOT_IMPLEMENTED, and that key alone often identifies the cause.

  4. The relevant log

    Section titled “The relevant log”

    The platform prints to the console it was started in. The runner writes to a file:

    Terminal window
    tail -n 200 ~/.local/state/commandchain-runner/runner.log     # Linux
    tail -n 200 ~/Library/Logs/commandchain-runner/runner.log     # macOS

    On Linux you can also follow the service with journalctl --user -u commandchain-runner -n 200. Restarting with LOG_LEVEL=debug gets a much more detailed log if the first pass is not conclusive.

Redact before you send

Section titled “Redact before you send”

Logs are written to be safe to share: credentials are masked, and the pairing credential is never printed. That is not a licence to skip a look. Check for anything from your own environment before you paste, particularly repository URLs that embed a token and anything from a project’s run environment.

Security reports

Section titled “Security reports”

If you believe you have found a vulnerability, do not open a public issue. Reply to your beta invitation email with the details, and say clearly at the top that it is a security report.

Before you write

Section titled “Before you write”

Two checks that resolve a surprising share of reports:

  • Are you on the current runner? Release notes lists what changed. Re-running the installer upgrades it, and keeps your pairing.
  • Does the FAQ already say it is intended? Several behaviors that look like bugs are deliberate: a run that waits rather than using the wrong coding agent, and a credential that can only be released once.

Next steps

Section titled “Next steps”