Hand off the task from the agent you already use.
Add one URL to Claude Code, Codex, or anything that speaks MCP. Then say what is wrong in a sentence, in the session where you hit it. The connector hands back a link — you open it, sign in with GitHub, and the posting starts from there.
Signing in is required. The detour is not.
Posting work here means a GitHub account, and there is no version of this where it does not — money, access and every decision hang off knowing who you are. What the connector removes is the part in the middle: stopping what you were doing, finding a web form, and writing the task a second time in a box.
- ▹You post as you — posting and every decision afterwards run under your own signed-in session. The connector does not route around that and is not meant to.
- ▹You write it where you hit it — you describe the task where you hit it, in the session you already had open. The connector hands back a link; you open it, sign in, and the posting starts there.
- ▹The connector cannot accept work or move money — it drafts, it reads, and — if you grant it — it publishes a draft you have already reviewed, which binds your saved card to that posting so a claimant knows the work is funded. Nothing is charged: accepting the finished work, and paying for it, happen in the browser under your own session.
Reading your postings back through the connector needs a token as well. You create one per client in the dashboard, it is shown once, and it keeps working until you revoke it. It is not your browser session and cannot stand in for one: it reads your postings, and publishes drafts only if you granted it that when you created it. It can never accept work or move money. An expiry was never what protected it either — you are emailed the moment one is created, which is the signal that catches a connector you did not make.
A stranger, without the keys.
Handing work to someone you do not know is really a question of what they can see, so that is the part we built first. How much they see is yours to set, posting by posting — and whatever you choose, they never get the ability to push to it. What comes back is a change, checked on our side before it reaches you.
- ▹You choose what they get — the files you list yourself, with your code never read; a slice we propose from your tree with our App on that repo, or from the file list you paste without it, once you confirm the counts; or the whole repository — your call, per posting. The first two are assembled here and sent, and neither hands over any repository access; the third hands the developer a read credential for the repo itself.
- ▹Secrets checked on the scoped tiers — when we assemble the files we check them first. A clear credential — a key, a token, a private key block — stops the hand-off outright. Two blurrier shapes, a password inside a connection string and a bare assignment that reads like a secret, we put in front of you instead, and they travel only if you tick each one. Choose the whole repository and nothing passes through us — there is no scan, we say so before you post, and rotating anything a stranger should not see is yours to do.
- ▹What comes back is checked — the change returns through us. A patch touching your CI setup, your git internals, your lockfiles or an install script is refused outright, and a new dependency applies unless you turn that off.
- ▹No push access, ever — the developer never gets push access to your repository. What they produce comes back through us, onto a branch of its own, and nothing merges until you accept it.
You choose what they see.
A posting is not an invitation into your codebase. You decide how much of it exists, as far as the developer is concerned. On the scoped tiers the files are put together on our side and scanned for secrets before any of it leaves; choose the whole repository and it goes to the developer directly, with no scan we could run.
- ▹What they see — the files you list yourself, with your code never read; a slice we propose from your tree with our App on that repo, or from the file list you paste without it, once you confirm the counts; or the whole repository. Set per posting — a one-line fix does not need your codebase.
- ▹What the job is — a failing test, a feature behind a flag, a migration nobody has time for. Scoped small enough that a diff answers it.
- ▹What lands — their work arrives on its own branch, checked before it does, for you to read. Nothing merges until you accept it.
Where this is today.
Handing off a task, matching it to a developer, returning a checked change, and releasing payment on acceptance all work now. While the numbers are small we watch every settlement ourselves.