Commonly asked questions
Find answers to the most frequently asked questions about theORQL here. If you have any other questions, feel free to contact us.
What is theORQL?
theORQL surfaces all frontend runtime data to help fix errors in your application. It integrates seamlessly with your existing development workflow - Editor > Browser > CI/CD > Build > Deploy and Production - to eliminate context-switching and provide intelligent debugging assistance.
How do I install theORQL?
Installing theORQL is simple. Available as a VSCode or OpenVSX (Cursor, Windsurf, etc.) extension, search for 'theORQL', and click Install. Once installed, you'll see the theORQL icon in your activity bar. Sign in and you're ready to start debugging your applications.
What types of bugs does theORQL resolve?
theORQL is best at debugging issues you can’t quickly reproduce or reason about from code alone: browser/runtime errors (including async promise failures), UI state bugs, flaky/edge-case regressions, and integration problems (API/network failures, bad responses, auth/session issues). It captures the real failure context (errors, console, request/response signals, and stacks) and turns it into actionable steps to isolate the cause and fix it.
What stacks does theORQL work best with today?
theORQL is designed for modern JavaScript/TypeScript frontends running in Chrome (for example React, Next.js, and other Vite/Webpack-based apps). Other frameworks work well as long as they run in a Chromium browser.
Does this run in production?
theORQL is built for local development and dev-like environments (dev/staging). It's not a full production monitoring or observability platform.
Will this slow down my dev environment?
No. theORQL only does work when the debugger is running and focuses on runtime errors and targeted traces. In normal flows, overhead is small compared to manually adding logs and refreshing repeatedly.
What data does theORQL capture?
When a runtime error occurs (or when you trigger a debugging flow), theORQL captures:
- Stack traces and selected source locations
- Local variables and relevant runtime values
- DOM state and URL at the time of the error
- Network requests/responses related to the error
- Console logs leading up to the issue
This is the same kind of information you would normally inspect in Chrome DevTools, organized so the AI can explain and help fix issues.
What does "vision-enabled coding + debugging" mean?
Most AI coding tools are text-only: they guess from your repo and prompts. theORQL is vision-enabled because it observes what your app actually renders and does at runtime (DOM, computed CSS, network, console, and visual evidence). That lets it map UI to code and verify outcomes in the browser so UI changes actually stick.
What is the Auto Repro -> Fix loop?
Auto Repro -> Fix is theORQL's runtime loop: reproduce the exact failure or user flow in the browser, apply a fix, then re-run and verify the result before handing you a reviewable diff. It is how theORQL turns "I can't reproduce it" bugs and "tweak -> refresh" UI work into a verified outcome.
How does Auto Repro help with frontend coding (not just debugging)?
Frontend coding is runtime correctness: layout, state, events, timing, and data all have to work in the browser. Auto Repro keeps a real user path replaying while theORQL iterates, so changes converge on what actually renders and behaves correctly. That reduces regressions and collapses the tweak -> refresh loop into a single verified iteration.
Does theORQL use screenshots or visual evidence?
Yes. As part of the runtime loop, theORQL can ingest visual evidence (screenshots) alongside DOM/CSS/state/network signals. This is used to verify that the UI actually changed as intended, not just that the code "looks right."
How is this different from Copilot or Cursor?
Copilot/Cursor are great at text-in, text-out code generation. theORQL is runtime-aware: it observes the running app in Chrome and maps UI or failures back to the owning code, then verifies fixes in-browser before producing a reviewable diff.
How do I install the extension?
Open VSCode Extensions, search for 'theORQL', click Install, then open the theORQL sidebar to sign in and start debugging.
What is the first-time setup flow?
Sign in from the sidebar, choose to use theORQL agentic AI (or bring your own API key), then start the debugger by entering your local dev URL (for example http://localhost:3000).
How do I rename a chat?
In chat history, open the chat menu and choose Rename. Or click the active chat title at the top and edit it inline.
How do debugging sessions work?
Start the debugger from the bug icon, use the launched Chrome instance (it is the one that captures errors), and the session stays synced with your VSCode project chat.
How do I connect Vercel or Netlify to monitor production errors?
Click “Click to start monitoring errors” in the header, set Error Source to Remote, choose Vercel or Netlify, and click Connect. Then paste a personal access token when prompted and select the correct project + branch.
Where do I get the Vercel or Netlify token?
Vercel: Account Settings → Tokens → create + copy token (scoped to the team/project). Netlify: User settings → Applications (OAuth) → Personal access tokens → New access token. Paste the token into theORQL; it stays on your local machine.
Why do I need to select the right project and branch?
theORQL can only propose code changes for the repo you have open in VS Code. Selecting the matching remote project and the branch that contains the failing deploy ensures the errors map back to the code the AI can actually fix.
What’s the difference between build errors and runtime errors (and why should I reproduce runtime errors)?
Build errors happen during compilation and are usually straightforward. Runtime errors happen on the live site. Vercel/Netlify don’t retain all logs historically, so you often need to reproduce the runtime error on the deployed URL while monitoring is active so theORQL can capture the evidence.
How do I use vision in my coding or debugging?
You do not need to toggle anything on. theORQL automatically uses runtime vision (DOM, computed CSS, console, network, and visual evidence) during its coding and debugging loops. If you want to target a specific UI element, use the Element Selector in the Chrome chat window to click the exact element you care about. That selection gives theORQL the precise element context to capture and map back to code.