skip to content

Hand off the task from the agent you already use.

If you are the person paying for the work, 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.

add the connectorone line
claude mcp add --transport http terminalhire-founder https://terminalhire.com/api/founder/mcp
// then, in the session you were already in
draft a terminalhire posting — the retry test in src/queue/retry.test.ts has been flaky for a month
Draft saved. Nothing is visible to developers until it is confirmed.

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 youposting 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 ityou 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 moneyit 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.

Read access, without push access.

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 getthe whole repository is the default: a read-only credential for that repo, including its history and every branch. You acknowledge that exposure before publishing. Or choose the files you list yourself, without granting repository access; or 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. Those two choices send the confirmed file list and any available contents, with no repository access — your call, per posting.
  • Secrets checked on the scoped tierswhen 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 checkedthe change returns through us. We refuse edits to recognized CI and build files, git internals, lockfiles and package.json scripts. A new dependency applies unless you turn that off. Unclassified manifest changes, detected network calls and obfuscation wait for your review.
  • No push access, everthe developer gets no push access from Terminalhire. What they produce comes back through us, onto a branch of its own. Accepting the work does not merge it; you decide when to merge.
lib/patchBoundary.tsvalidated
// what stands between them and your repo
allow the change, on a branch of its own
allow verification → your own CI
flag network calls · obfuscation
deny .github/workflows · lockfiles
deny push access, always
// refuse on doubt — the refusal names the file

You choose what they see.

Whole-repository access is the default, with a required exposure acknowledgment before you publish. The files go from GitHub to the developer, and we do not scan them. You can choose a scoped tier instead; those files are put together and checked for secrets here before they leave.

  • What they seethe whole repository, read-only, by default. You can instead choose the files you list yourself, without granting repository access; or 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. Set per posting.
  • What the job isa failing test, a feature behind a flag, a migration nobody has time for. Scoped small enough that a diff answers it.
  • What landstheir work arrives on a branch of its own for you to read. Your default branch stays unchanged until you merge 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.