Osloq

An AI agent that reproduces GitHub issues for you

Developer Tools

Artificial Intelligence

GitHub

Visit WebsiteSee on Product HuntTwitter ⧉

@enessss since Osloq stops at a confirmed repro with evidence rather than proposing a fix, is the output structured enough, or is it more of a human readable triage report at this stage?

the hard part with most repro bugs I've dealt with isn't running the code, it's the missing state - a specific user's data, a race condition that only shows up under load, third party API responses that vary. how does the sandbox handle issues that need real production-like data or timing to actually trigger, or is this mostly aimed at the straightforward "steps to reproduce" kind of bug

the setup loop is the sharp edge — the agent iterates until the repo's up. but a whole class of bugs is 'doesn't build on clean checkout,' and something whose job is to get it running will quietly patch past exactly that.

Running the actual code instead of reasoning about it is the right call. Curious how Osloq handles repos with external service dependencies - database calls, third-party APIs - where the bug only shows in a specific environment setup.

Hey Enes, the reproducing part has always been the bit that quietly eats my afternoon, so seeing something take that off my plate genuinely made me pause. Feels like the kind of help I'd actually welcome.

How does the sandbox handle repos with heavy infra dependencies like docker compose or database services. Does it spin those up too or just the app code in isolation?

I would like support for retrying failed reproductions. Multiple execution attempts could separate random failures from actual bugs.

The evidence-backed part is the important line here. For a small team, a bug-repro agent is useful only if the report can become a reviewable artifact: exact assumptions, commands, env gaps, and ideally a tiny failing test or script someone can rerun. That keeps it from turning into another confident AI opinion in the triage queue.

Curious how it handles repos with external service dependencies like a database or third party API. Does the sandbox spin those up too, or do I need to provide credentials before it can run anything?

The "no evidence, no claim" stance is the right call — I build agents for commerce checkout flows, and verifying an agent's claims against what actually ran is where most of our engineering time goes too.

Two things I couldn't tell from the page: how do UI-only bugs work — if an issue only reproduces in a rendered front-end (dead button after hydration, checkout step breaking), does the sandbox drive a real browser, or is it limited to what's exercisable from CLI and tests?

And how do you keep the agent itself honest over time — do you re-run it against a benchmark of previously-verified issues when prompts or models change, so repro accuracy doesn't silently regress?

Congrats on the launch @enessss

Neat concept. Does it handle bugs that need specific user state or production data to actually reproduce?

Tried it on a tricky bug I'd been putting off and the agent actually cloned the repo and walked through reproduction steps I hadn't even considered. Loved that the report felt grounded in real output rather than speculation.

the no-setup sandbox thing is such a smart move, you skip the half-day yak-shave of replicating someone else's machine just to confirm a bug. nice execution.

Reproducing the issue is genuinely the worst half of the job - half the tickets I get are 'it doesn't work' with zero context, and you burn an hour just recreating the state before you can even start fixing. Automating the boring forensic part instead of the fix itself is a smart wedge. How does it handle issues that need specific data/state to trigger? Congrats on the launch.

Really interesting approach!!!!
Curious....how does Osloq handle issues that depend on external services or environment specific configurations?
Anyways...congrats on the launch! 🚀

The sandbox repro thing is genuinely cool, I picked a flaky issue from one of my repos and it came back with actual logs and the failing test. Wish I'd had this last week when I burned an afternoon chasing a "bug" that turned out to be a stale local DB.

How does it handle repos that need specific env vars or a database to actually run, does it ask me to configure those or just spin up a blank sandbox and fail?

Really interesting approach. How reliable has Osloq been at reproducing tricky bugs without false positives?