Privacy Policy

1. Who we are

Terminalhire is operated by Staqs, Inc. (“staqs”, “we”, “us”), registered at 251 Little Falls Drive, Wilmington, DE 19808, USA. For privacy questions or to exercise your rights, contact us at privacy@staqs.io.

Data protection / privacy contact: No Data Protection Officer has been appointed; privacy inquiries are handled by Staqs, Inc. at privacy@staqs.io. . EU/EEA representative under Article 27 GDPR: No EU representative has been appointed at this time; EU/EEA users may contact privacy@staqs.io. . UK representative, if applicable: No UK representative has been appointed at this time; UK users may contact privacy@staqs.io.

2. What data we handle

We group everything into three buckets, in order of how protective each is of your privacy.

2a. Data that stays on your device (never transmitted unless you consent)

The following lives only in your local Terminalhire installation and is never sent to us unless you take a specific opt-in action described in bucket 2c:

• •An encrypted local profile (~/.terminalhire/profile.enc, encrypted at rest with AES-256-GCM): your skill tags, GitHub-derived public data, an optional display name and contact email you set yourself, and your saved jobs.
• •A GitHub OAuth token, stored encrypted on your device, with scope read:user (public data only — we never request or access private repositories).
• •Your profile never leaves your device — job matching runs against an anonymously downloaded job index. No fingerprint and no profile is sent to perform matching.
• •Employer-repository sessions are excluded by default from profile building, to avoid capturing an employer's confidential or proprietary information.

2b. Anonymous processing (no developer identity)

• •Job index download (GET /api/index): an anonymous download of the public job index. No cookies, no identifiers, and no profile are included in the request.
• •Click tracking: links of the form terminalhire.com/j/<source>/<id> redirect (HTTP 302) to the real job listing and log an anonymous event consisting of the job id, source, company, and timestamp. This event contains no developer identity and no profile. Our hosting provider may transiently process IP addresses for security and operational purposes.
• •Aggregate “matched” count: when the developer-directory match runs against a profile that never leaves your device, the CLI may report an anonymoussignal consisting only of the public GitHub logins of the developers and projects you were matched with, so each of those builders can see an aggregate “you were matched N times” count on their own dashboard. This request carries no cookie, no identifier, and no developer identity — it never includes your profile, your skill fingerprint, or who did the matching, and no per-viewer record is stored.
• •Product analytics: the website records named steps on the two paths through it — posting work, and claiming it — so we can see where people get stuck. Each event carries a step name, a step number, and a few tags (which refusal a publish hit, whether a posting is paid), plus which of our deployments recorded it and — on product events — which of our own surfaces it came from (web, CLI, MCP or our verification worker); error reports carry the deployment but not always the surface. Both describe our software, not you. While you are signed in it is tied to your public GitHub login; signed out, each event gets a throwaway id and no profile is built. We never send an email address, a token, a session id, repository contents, a patch, or the text of a posting. There is no autocapture — we record the steps we named, not every click you make. We do record a masked session recording: the shape of the page and what you clicked, with all text and every form field masked in your browser before anything is sent, so a recording shows where you moved and got stuck, and the address of each page with any share-link token or checkout session id taken out, but not the words on it or anything you typed. We also send error reports and server logs when something breaks. An error report carries a stack trace and the error message, with addresses and token-shaped strings redacted from the message. No advertising or cross-site trackers, and no analytics cookies. See the Cookies & analytics section below.

2c. Consented data egress (explicit, per-event, opt-in)

These are the only ways identifying data leaves your device. Each requires a deliberate command and an on-screen confirmation that names the recipient.

• •Tier-1 opt-in profile sync. When you run terminalhire sync --pushand type “yes” to a consent card that names “staqs (terminalhire.com)”, a one-time snapshot of your GitHub-public profile fields (GitHub login, name, public email, top languages, skill tags) plus the display name and contact email you set yourself is stored on our server (a Neon PostgreSQL database). It is revocable at any time with terminalhire sync --delete, which performs a hard delete. This sync never stores private repositories, employer-repo-derived tags, raw code, access tokens, session context, or file paths.
• •Opt-in dashboard claim view. When you run terminalhire claim --push, type “yes” to a field-level consent card, and confirm in the browser (signing in with GitHub to prove the account is yours), a minimal, score-free snapshot of your own posting and contribution claims — the kind of work, the public repository, a coarse status (claimed / in-progress / merged), the public pull-request link, a merged yes/no flag, and timestamps — is stored on our server (a Neon PostgreSQL database) so it can appear on your own dashboard. It never includes your diff-acceptance score, review notes, branch names, worktree paths, repository policy results, or any private data. You can hard-delete it at any time with terminalhire claim --push --revoke or the “delete my pushed claims” button on your dashboard.
• •Lead sharing. Per opportunity, you are shown an explicit named-buyer prompt (for example, “Share with Northstar Talent Partners? yes/no”), and only if you answer “yes” is a lead payload (the approved profile fields) sent to that named partner agency. Each partner agency signs a per-partner DPA before it can receive any lead. The partner agency is an independent controller for recruiting purposes, governed by our Data Processing / Data Sharing Agreement.

3. Purposes and lawful bases

For developers in the EU/EEA and UK, we rely on the following lawful bases under the GDPR / UK GDPR:

• •Consent (Art. 6(1)(a)): Tier-1 profile sync and each lead share. You give consent through the named, per-event prompts described above, and you may withdraw it at any time.
• •Legitimate interests (Art. 6(1)(f)): anonymous click analytics, product analytics (the named posting and claiming steps described in section 4), and the security/operational processing of transient IP addresses — to understand aggregate engagement, to find where the product gets in your way, and to protect the service. We have weighed this against your rights and freedoms (balancing test); the click events carry no developer identity at all, and the product-analytics events carry your public GitHub login and a step name and nothing more, so the impact on you is minimal. You can object — see your rights below.

4. Cookies & analytics

terminalhire.com sets no analytics, advertising, or cross-site cookies and runs no advertising or cross-site trackers. The Terminalhire CLI and plugin do not use cookies.

We collect two usage signals. The first is the first-party anonymous click event described in section 2b (job id, source, company, timestamp — no developer identity, no profile), which is logged server-side and sets no cookie. The second is product analytics, processed by PostHog (see section 5): named steps on the posting and claiming paths, so we can see where people get stuck. It stores a local-storage entry in your browser holding an identifier for these events, and no cookie. While you are signed in the events carry your public GitHub login; signed out, each gets a throwaway id and no profile is built. Autocapture is off, so what is recorded is the named steps and their tags — never an email address, a token, repository contents, a patch, or the text of a posting. When we read a poster's repository to scope a posting we also record how big it was— counts of files, bytes and lines, the repository's numeric GitHub id, and whether we downloaded it or reused a copy, or which size limit stopped us reading it — and never a file name, a path or any of its contents. The copy we read is the repository at the scoped commit, kept on one server's temporary disk and reused for at most an hour after it was downloaded, never after; an expired copy is deleted the next time that server downloads a repository, or when the server is recycled. Your GitHub App access is checked again before every read.

PostHog also receives masked session recordings, error reports and server logs. A recording captures the structure of the page and your interactions with it — clicks, scrolling, navigation — and every piece of text and every form field is replaced with a placeholder in your browser before the recording is sent. That means a recording can show us that you stopped on the payment step and clicked the same button three times; it cannot show us your email address, the text of your posting, or anything you typed. It does carry the address of each page, as the analytics events from your browser do, and some addresses name a public repository (/projects/owner/repo). Before anything is sent, the token is taken out of every share, claim or draft link (the part after /c/, /t/, /dashboard/work/ or /founder/confirm/), and so is the value of every query parameter except which dashboard tab is open. Error reports carry the error type, a stack trace, and the message with addresses and token-shaped strings redacted before they are sent. Server logs are lines our own code writes about what it did — never request bodies.

The only cookies we set are strictly necessary session cookies that keep you signed in to authenticated areas (the dashboard, recruiter portal, and admin) when you choose to log in. These are exempt from prior-consent requirements because they are essential to a feature you explicitly requested. Our hosting provider may transiently process IP addresses for security and operational purposes, as described above.

5. Sub-processors & third parties

This list is current as of the effective date. We will update it as our sub-processors change: The sub-processors listed above (Vercel, Neon, GitHub, and Google) are the complete current list; data-processing terms are in place with each. .

6. International transfers

Our servers and the third parties above are located in the United States (Vercel and Neon host in the US). If you are in the EU/EEA or the UK, any transfer of your personal data to the United States relies on appropriate safeguards — the EU Standard Contractual Clauses (SCCs), the UK International Data Transfer Agreement (IDTA) or Addendum, and/or an adequacy mechanism, as applicable. Specifics to confirm: [to be finalized with counsel: confirm transfer mechanism per recipient (SCCs / UK IDTA / adequacy / DPF certification)].

7. Data retention

• •On-device data: kept locally on your machine until you delete it. You control it directly.
• •Tier-1 synced profile: retained until you revoke it (terminalhire sync --delete) or after 24 months of inactivity, whichever comes first.
• •Anonymous click logs: retained for 12 months , then deleted or further aggregated.
• •Shared leads: once a lead is shared with a named buyer, that buyer becomes an independent controller and applies its own retention, governed by the per-partner DPA.
• •Our record of each payout we made to you stays, with your GitHub account id on it, because we keep payment records for tax and accounting.
• •A sign-in or CLI token from before you asked us to delete your account can't claim work afterwards. While deletion is running it gets “Your account is being deleted, so you can't claim new work.”, and after that “This account has been deleted, so you can't claim new work.”

8. Your rights

EU/EEA & UK (GDPR / UK GDPR)

Subject to applicable law, you have the rights of access, rectification, erasure (“right to be forgotten”, Art. 17 — including via terminalhire sync --delete, which hard-deletes your synced profile), restriction of processing, data portability, objection to processing, and the right to withdraw consent at any time without affecting processing already carried out. You also have the right to lodge a complaint with your supervisory authority.

California (CCPA / CPRA)

If you are a California resident, you have the rights to know, access, correct, and delete your personal information, the right to opt out of the sale or sharing of personal information, and the right not to be discriminated against for exercising these rights.

We do not sell your personal information — with one possible exception you control: the consented, developer-initiated lead share that you explicitly approve to a named buyer. [to be finalized with counsel: counsel to confirm whether the consented lead share constitutes a “sale” or “sharing” under CCPA/CPRA and update this disclosure and any opt-out mechanism accordingly]. We never sell or share the anonymous or on-device data described above.

9. Automated decision-making & profiling

Terminalhire does not make solely-automated decisions that produce legal or similarly significant effects about you (GDPR Art. 22). Job matching is a suggestion tool: it matches public job postings to your skills using a profile that never leaves your device, and you decide whether to apply. This profiling has no legal effect and never determines an outcome on its own.

10. Security

• •Your local profile is encrypted at rest with AES-256-GCM.
• •Data in transit is protected with TLS.
• •GitHub access is minimized to the read:user scope (public data only).
• •Employer-repository sessions are excluded from profile building by default.
• •Server-side Tier-1 data is stored in Neon with encryption at rest.

No system is perfectly secure, but we work to protect your data using measures appropriate to the risk.

11. Children

Terminalhire is not directed to, and is not intended for use by, individuals under the age of 16. We do not knowingly collect personal information from children. If you believe a child has provided us data, contact us at privacy@staqs.io.

12. How to exercise your rights

Email us at privacy@staqs.io. For the data you control directly, you can also use the CLI:

• •terminalhire sync --delete — hard-delete your server-side Tier-1 profile (erasure).
• •Delete your local installation and ~/.terminalhire/ directory to remove all on-device data.

13. Changes to this policy

We may update this policy from time to time. When we do, we will revise the “last updated” date and, where required, provide a more prominent notice. Material changes will be communicated as required by law.