Skip to main content

Automatic capture (CLI)

Once the CLI is set up, Multiplayer runs in the background and starts a new debugging session on its own the moment an error or exception occurs in your app.

For capturing a bug yourself, on demand, from the browser, see the "Manual capture" section on how to use the browser extension or in-app widget.

CLI setup​

Multiplayer CLI setup screen offering "Try a demo" or "Setup existing project"

One copy/paste this command in your terminal:

npm install -g @multiplayer-app/cli && multiplayer

The setup wizard walks through six steps: authentication, repository directory, model selection, session recorder SDK detection, and verification. Once it completes, the CLI runs as a background process and automatic capture is live. For the full step-by-step walkthrough, see the quickstack.

Type of bugs captured automatically​

Multiplayer listens for two categories of failure, exceptions and errors, which aren't the same thing in OpenTelemetry terms.

Exceptions are a specific kind of error: a throw in your code that gets caught and logged. In JavaScript that's throw new Error(...), in Java, Python, or Go it's a thrown and caught exception. OTel has a standard convention for these: exception.type, exception.message, exception.stacktrace.

Errors are the broader category, "something went wrong" that isn't necessarily a language-level exception. An HTTP 500, a failed file open, a database query timeout, none of these throw an exception in the runtime, but all of them get marked as error spans in traces (status.code=ERROR). Every exception is an error. Not every error is an exception.

Multiplayer triggers a session on three conditions:

  • Frontend exception. A JS runtime error thrown by the app.
  • Backend error. Any span with status=ERROR, a failed HTTP call, a DB timeout, or similar.
  • Programmatic trigger. Set multiplayer.session.auto-save=true as a custom attribute on any span, and Multiplayer saves the current rolling buffer at that point, independent of whether an error occurred.

What happens when a bug is captured​

A Multiplayer agent session working through a captured issue: reading the relevant files, identifying the root cause, applying a fix, and preparing to open a PR

Multiplayer saves the session, correlated across frontend and backend, and checks it against existing issues. If it clears the fixability bar, an agent picks it up, prompts your coding agent and opens a new PR when the fix is ready.

This is the same recording, issue, and agent flow covered in How the debugging agent works.

Controlling what happens automatically​

CLI settings panel showing the auto-resolve issues toggle and git operation options: dry run, local commit, or open pull request

The settings screen in the CLI controls how far Multiplayer goes on its own.

  • Auto-resolve issues. When on, Multiplayer routes fixable issues to an agent without waiting for you to trigger it manually per issue.
  • Git operations. Controls how far an agent goes once it has a fix: apply patches only with no commit or push (dry run), create a branch and commit locally with no remote push, or branch, commit, push, and open a PR. An advanced view lets you fine-tune each step individually.
  • Environments and components. Scope automatic capture to specific environments or services instead of everything the SDK is installed in.

If you're rolling this out to a team for the first time, starting with dry run and a narrow environment scope, then widening it once you trust the fixability scoring, is a reasonable way to build confidence in what gets triggered before handing it write access to your repo.

Next steps​

🚀 If you’re ready to trial Multiplayer with your own app, you can follow the steps in the quickstart.

📌 If you have any questions shoot us an email! 💜