How bugstack works

bugstack watches your running app, your deploys and your repository. When something breaks, it works out the cause, writes the change, and sends it as a pull request. Here is each step, and where you stay in control.

The short version

bugstack does three things:

1. Watch — Your app reports crashes through the SDK. Your host reports failed deploys. bugstack reads your repository on a schedule.
2. Fix — A coordinator assigns specialist agents to each problem. They find the cause and write a change small enough to review.
3. Prove and control — The change is checked against your autonomy level and safety rules. Then it is drafted, opened as a pull request, or merged, and the outcome is recorded.

Watch: three ways a problem arrives

1. Crashes, through the SDK

The bugstack SDK attaches to your framework’s error paths — Express error middleware, Next.js instrumentation.ts, Django middleware, Flask error handlers, Rails rescue_from, or Go recovery middleware. When an unhandled error occurs on your server, the SDK collects:

• Error name, message, and full stack trace
• Parsed stack frames (file, function, line, column)
• Environment metadata (language version, framework, OS, SDK version)
• A fingerprint hash for deduplication

The JavaScript SDK captures full request context by default (route, method, status code, URL, query params, request body, headers). The Python, Ruby, and Go SDKs capture minimal error metadata only — no request bodies unless explicitly enabled.

All payloads pass through automatic redaction before transmission. Capture is non-blocking: it does not add latency to your request/response cycle.

2. Failed deploys, from your host

When you connect a host, bugstack hears about deploys that fail and starts work on the cause. Render is the host supported today. Deploys on hosts that are not connected are not seen.

3. Repository scans, on a schedule

Connecting your GitHub repository also starts repository scanning. bugstack reads the repository on a clock:

• Vulnerable packages — every four hours
• Secrets — nightly
• Outdated packages — daily

bugstack scans and reports these findings. It can also open pull requests for dependency and security findings. That is switched on per account.

One problem, one fix

Each error is assigned a fingerprint hash based on its error type, message pattern, and stack trace. If the same fingerprint appears within the deduplication window (default: 5 minutes), the duplicate is batched with the original and not re-processed as a separate fix. This prevents a single cascading failure from generating dozens of identical pull requests.

Fix: specialist agents

Once something is detected, a coordinator assigns the work to specialist agents:

• Fixer — reads the code and writes the patch
• Tester — reproduces the failure
• Security, dependency and infrastructure specialists — handle findings in their own areas

Not every crash can be fixed with a code change. Errors caused by infrastructure (DNS, network timeouts, a full disk) or by configuration (a missing environment variable, wrong credentials) are still reported in your bugstack dashboard, but bugstack does not write a code patch for them.

Fix: what bugstack reads

For a crash fix, bugstack pulls the relevant source files from your GitHub repository: the files referenced in the stack trace and their immediate dependencies. Repository scans are different. They read the repository as a whole, because that is what a scan is.

File access uses your own GitHub token, which is encrypted at rest with AES-256-GCM. Per-user isolation ensures that tokens are never shared across accounts.

Fix: writing the change

Fixes are written by Anthropic’s Claude. For a crash, the error, the stack trace, and the retrieved source files are sent to Claude, which works out the root cause and produces a minimal diff — changing only what is necessary to resolve the error without altering unrelated behavior.

Most error fixes are small. One that changes more than 3 files or 30 lines is still proposed, and it always waits for your review, whatever level you have set.

Prove: the pull request and your CI

Every change is a pull request. bugstack creates a new branch on your repository and opens a pull request with:

• A clear title describing the problem and the fix
• A detailed description with the error message, stack trace, and explanation of the change
• The minimal diff produced in the previous step

Your CI runs on the pull request as it would for any other (GitHub Actions, CircleCI, Jenkins, or any provider that reports status checks on pull requests). bugstack reads the result. It does not bypass your checks.

Control: three autonomy levels

You set an autonomy level for each repository from the dashboard. New accounts start at the review level.

• Draft fixes for me — bugstack drafts the fix and waits for you
• Open PRs, I merge — bugstack opens the pull request; you review and merge (the starting level)
• Fix & merge for me — autopilot: bugstack opens the pull request and merges it once the proof is in

What autopilot requires

• Green CI on the pull request
• A reproduction of the failure that failed before the fix and passed after

Sensitive actions always wait for a human, at every level: secret rotation, infrastructure changes, and deploy rollbacks.

The audit log and undo

Every decision bugstack makes lands on a tamper-evident audit log. Nothing happens off the record.

Undo is a pull request too. Reversing a change opens a revert pull request on your repository.

What bugstack does not watch

• Wrong answers returned as a success
• Anything that does not throw: a job that quietly stops, a page that gets slower
• Errors in your users’ browsers
• Deploys on hosts that are not connected

Next steps

• Data and privacy — exactly what the SDK sends and how data is handled
• Quickstart — install the SDK and connect your repository
• Security — encryption, isolation, and compliance details