FAQ

Ribix connects via the URL you provide during ribix connect. It supports three auth methods:

• Bearer token - send an Authorization: Bearer <token> header on every request.
• Session cookie - send a named cookie on every request.
• None - for public or IP-restricted environments.

Credentials are encrypted at rest with AES-256-GCM. See Integrations for full setup details.

Never. Ribix only runs against the staging URL you configure with ribix connect. It never makes requests to any other environment, and production is never touched. The CLI enforces this at the workspace level - you must explicitly configure and connect a URL before any run can happen.

When the browser or API agent detects an anomaly, Ribix runs through a multi-step loop:

1. Classify - severity is assigned (P0–P3) based on the type and impact of the anomaly.
2. Write a test - Ribix generates a failing test in your existing test framework (Jest, Vitest, Pytest, or Go test) that proves the bug is real.
3. Generate a fix - an LLM produces a minimal patch. Ribix runs your full test suite against the patch. If tests still fail, it retries up to 3 rounds before flagging the finding as “needs human.”
4. Present for approval - you review the test, diff, and test results. Nothing is opened as a PR until you explicitly approve.

See How It Works for the full flow.

No. Every fix goes through an explicit approve/reject gate. You run ribix approve <id> or click Approve in the dashboard, and only then does Ribix open the GitHub PR. There is no automatic PR creation. If you want to reject a finding entirely, use ribix reject <id>; it will not appear in future runs.

Ribix currently supports Jest, Vitest, Pytest, and Go test. The framework is auto-detected from your repository configuration:

• Jest / Vitest: detected from devDependencies in package.json.
• Pytest: detected from pyproject.toml or requirements.txt.
• Go test: detected from go.mod and the presence of _test.go files.

You can pin the framework with ribix connect --framework <name>. Additional framework support (Mocha, RSpec, etc.) is on the roadmap.

An agent run is one session where the Ribix proactive agent explores your staging environment - triggered by a code push via the GitHub App webhook or by a manual ribix run. Each run may discover zero or more findings. Enrichments (reactive mode, where Ribix responds to GitHub Issues you file) are billed separately and counted per issue enriched.

No. Ribix reads your repository during analysis to compute blame, identify candidate files, and generate fix diffs, but it does not write your source code to a database. Code is processed transiently in memory. What is stored is the output of that analysis: finding records, proposed diffs, enrichment comments, and blame attribution metadata. See Security & Privacy for the full data inventory.

Ribix runs your full test suite against every proposed fix before surfacing it to you. If the patch breaks existing tests, Ribix retries with a revised approach - up to 3 rounds. If it cannot produce a green patch after 3 attempts, the finding is flagged as “fix failed - needs human”. You still see the failing test and the diagnosis; only the automated fix attempt is marked as incomplete. You can reject the finding or fix it manually.

Email privacy@ribix.dev with your account or workspace identifier. We process deletion requests within 30 days. A self-serve account closure flow is on the product roadmap. See Security & Privacy → Data deletion for details.

Partially. The proactive agent (ribix run) works without the GitHub App - it connects directly to your staging URL and reports findings to the CLI and dashboard. However, the GitHub App is required for two things: (1) reactive enrichment on issues you file in GitHub, and (2) opening PRs from approved findings. Without the App, you can still view and approve findings in the CLI, but you will need to apply the fix diff manually.