Launching today
Osloq
An AI agent that reproduces GitHub issues for you
59 followers
An AI agent that reproduces GitHub issues for you
59 followers
Most AI dev tools just read your code and guess. Osloq actually runs it. Connect your GitHub, pick an issue, and an AI agent spins up a real sandbox, clones your repo, runs it, and tries to reproduce the bug the way a developer would. You get a report backed by real evidence. What happened, the steps it took, and whether the bug is real, not a hallucinated guess. No local setup, no "works on my machine." It handles the tedious reproduction step so you jump straight to fixing.
hey, product hunt! 👋
i'm enes, solo founder of osloq.
this came from a problem every developer knows too well. someone files a bug report, and before you can even think about fixing it, you drop what you're working on, dig through the repro steps, get your project into the exact state they described, and run it over and over just to confirm the bug is even real. half the time it ends in "works on my machine" and the issue sits there for weeks.
so i built osloq to do that part. you hand it a github issue, and it spins up a real sandbox, clones and runs your actual repo, and tries to reproduce the bug the way a developer would. then it hands you a report backed by real evidence. what it did, what happened, and whether the bug is actually real.
the hardest part while building it was trust. early on the agent would "reproduce" bugs that weren't real, basically confident hallucinations. so a lot of the work went into making it run real code and prove what it found, instead of guessing from reading the source. if it can't back a claim with evidence, it says so.
it's live today and i'd genuinely love your feedback. what would make this useful in your workflow? ask me anything, i'll be here all day.
The "spins up a real sandbox, clones and runs your actual repo" step is the hard part — most repros only fire with real env config, not just the issue text. To get a project runnable, does Osloq read a devcontainer/Dockerfile/build script or infer the setup itself? And for bugs that need secrets or a seeded DB, how is private-repo access scoped — a short-lived token per run, or standing access?
great question! yeah that's the hard part. no devcontainer needed, the agent works out the setup from the repo itself, installs, runs, and iterates until it's up. for bugs that need real config you can add project secrets, encrypted and only decrypted inside the sandbox, never logged, and if a secret turns out to be invalid or a service can't be reached (say an expired token or a bad db url), it can swap in a local stand-in to still reach the reported code path. access is through the github app with a short-lived token per run, nothing standing
Foyer
Reproducing issues is genuinely one of the more annoying parts of the bug triage loop, especially when the report is half-baked and the reproducer assumes environment context the submitter forgot to mention. Curious how Osloq handles that case. When the issue is ambiguous or missing key details, does the agent ask clarifying questions, make assumptions and document them, or just fail gracefully and tell you what it couldn't figure out? Also wondering whether the reproduced case outputs something like a failing test or a script, or just a description of the steps it took.
@fberrez1
hey! since a run is autonomous it doesn't stop to ask mid-way, it figures out the intended behavior from the repo and makes its best attempt, documenting what it assumed. if it can't pin it down, it won't fake a result, it comes back as not reproduced or blocked and tells you what it couldn't figure out. but yeah, having the agent ask a clarifying question mid-run is something i've had in mind and want to add down the line, could be really useful. for your second question, you get the steps plus the real evidence behind them (the commands it ran and what actually happened)
Love the emphasis on "backed by real evidence" instead of confident hallucinations, that's the biggest friction point with most AI dev tools right now. The sandbox approach is solid.
Quick question though. How does it handle intermittent bugs or race conditions? Those are the worst to reproduce manually, but I imagine they're also tricky for an agent since a single run might not catch them. Does it retry, run multiple times, or is that something you need to flag upfront?
@inescastillo hey! honestly this is one of the hardest cases. right now the agent already re-runs the reproduction on its own if the first attempt doesn't fire, and it grades its own confidence so it won't overclaim if it only caught it once. what it doesn't do yet is the heavier version, being told upfront "this one's intermittent" so it runs it far more times, and stressing it under real concurrency to force a race rather than just repeating the same call. both of those are high on the roadmap
Really smart move focusing the agent on reproducing issues specifically, instead of trying to fix everything. Repro is the annoying part that eats up so much of my morning, and getting a clean repro is half the battle anyway.
@yibo_wang3 thanks! yeah, that's exactly the bet
actually runs the repo in a sandbox to verify bugs, that part genuinely sold me. way more useful than the usual "here are 5 possible causes" guesswork from other tools.
@eminenv9f thanks! that was exactly the goal