Cursor Originは、Cursorが出しているGitホスティングです。リポジトリを置いて、レビューして、マージする。GitHubやGitLabと同じ役割です。公式のコピーは "A git forge for the agentic era"。人間が1本ずつPull Requestを出す速度ではなく、エージェントが短時間に大量のブランチと差分を出す前提で作られています。
Cursor Ambassadorには少し早めにリリースされたので、すぐに試しました。そして書いている途中の2026年8月17日、初期ベータとしてすべての有料プランへ順次提供が始まりました。管理者がオプトアウトした企業組織を除き、有料プラン（Pro / Teams / エンタープライズ）ならもう使えます。レガシー版プライバシーモードのチームは、新しいプライバシーモードへ切り替えるまで有効化できません。公式ドキュメントも公開されています。既存のGitHubリポジトリをOriginへ載せて分かったことの前編です。Originが何で、GitHubと何が同じで何が違うかを、画面とCLIで確認できた範囲で書きます。Pull Requestの内部モデル、remote名の罠、CIとrulesetの組み立ては後編に分けました。
後編はこちら: https://qiita.com/Kinopee/items/747de22525344a796eed
試したのは2026年8月17日の夜です。ちょうどGitHubが障害の真っ最中でした。Webの画面は "We couldn't respond to your request in time." を返していて、触った初日に、push先がもう一つあるありがたみを身をもって知りました。この話は後半に回します。
何をする場所か
すごく雑に言うと、CursorアカウントでログインするGitHubです。ホストは origin.cursor.com。Gitの操作は普通のGitで、commit / branch / push / pull / clone はそのまま使えます。
セットアップは2行です。GitHubのPATや gh auth は使いません。
curl -fsSL https://downloads.cursor.com/origin/install.sh | sh
origin auth login
origin auth login が認証して、origin.cursor.com 用のcredential helperをgitに設定します。以降の git push / git pull に、別トークンを手で入れる必要はありません。CLIはmacOSとLinux（WSLを含む）対応。ネイティブWindowsはまだ使えません（CLIドキュメント）。
紛らわしいことに、CLIの名前も origin です。gitのremote名として慣習的に使う origin とは別物なので、読み分けてください。
リポジトリやPull Requestの管理は、gh の代わりに origin を使います。
origin repo list # リポジトリ一覧
origin repo create <name> # 作成
origin repo clone owner/repo # clone
origin pr create # PR（change）作成
origin pr merge --auto # 条件が揃ったらマージ
既存のGitHubリポジトリを載せるのも、remoteを足してpushするだけです。既存の origin（GitHub）は触らず、別名で足すのが安全です。理由と落とし穴は後編に書きます。
もうひとつ、正式リリースで入ったGitHub同期もあります。GitHubリポジトリを取り込むと、同期済みリポジトリとしてリアルタイムに更新され、PRのコメントも双方向に同期されます。ただしこちらはGitHubが正本のままで、pushは引き続きGitHubへ送られます。CLIには origin repo create-mirrored があります。
git remote add cursor https://origin.cursor.com/owner/repo.git
git push cursor main
GitHubと何が同じで、何が違うか
同じなのはGitの中身です。コミット、ブランチ、タグはそのまま載ります。違うのはその周りです。
| 項目 | GitHub | Origin |
|---|---|---|
| ホスト | github.com | origin.cursor.com |
| 認証 | GitHubアカウント / gh
|
Cursorアカウント / origin CLI |
| 公開リポジトリ | できる | できない（チーム内のInternal / Privateのみ） |
| Issues / Actions / Releases | ある | ホスト側には無い。CIはAppsで外付け |
| Pull Request | 新規はopenが普通 | changeと呼ばれ、既定はdraft。版（version）を持つ |
いちばん驚いたのは、公開リポジトリにできないこと。公開範囲は、チーム全員が見られるInternalと、許可したメンバーだけのPrivateの2種類で、インターネットへの公開はありません。OSSの配布場所としては、今は使えません。
IssuesやActionsの実行履歴のような「ホスト側のデータ」は、gitのpushでは移りません。.github/workflows のYAMLはリポジトリ内に残りますが、Origin上でGitHub Actionsが動くわけではありません。CIはAppsという仕組みで、外部サービス（Buildkite、Depot、Vercel）を繋ぎます。
Pull Requestは見た目こそ近いですが、内部のモデルが違います。Originの単位は、changeと呼ばれる版（version）付きの差分です。GitHubのPull Requestは、コミットが積もるたびに中身が動きます。エージェントが短時間に何度も直すと、レビュアーは動き続けるdiffを追いかけることになります。Originはpushのたびに、その時点の差分をversionとして自動で記録します。レビューは「どの版を見たか」を固定でき、承認した対象が後から動きません。新規changeの既定がdraftなのも、小さなchangeを積み上げるstacked diffsのオプションがあるのも、同じ発想です。ここがOriginのいちばん面白いところなので、後編で図付きで書きます。
GitHubが止まる日の保険になるか
障害の頻度は、体感だけではありません。この夜の障害を GitHub Status で追うと、IssuesとPull Requestsの劣化から始まり、Actions、Webhooks、API、Git操作まで広がっていました。8月6日にはActionsが約9時間劣化し、ピーク時はワークフローの71%がインフラ起因で失敗しています。GitHub自身が月次の可用性レポートで unacceptable（許容できない）と書いた規模です。外部の集計では、直近1年のmajor扱いの障害は48件。2025年12月以降は頻度が上がっています。
gitは分散なので、ローカルのcommitは障害中も進みます。止まるのはホストに集まる部分、つまり共有とレビューとCIです。remoteが二つあると、このうち共有は逃がせます。GitHub側が落ちていても git push cursor main は通り、別のマシンやメンバーはOriginからpullできます。今回Originへ main をpushしたのは、GitHubがPull Requestsの劣化を報告している最中でした。Origin側のpushは普通に通りました。
注意したいのは、正式リリースのGitHub同期（ミラーリング）は、そのままでは避難先にならないことです。あちらはOrigin側に読めるコピーを作りますが、pushはGitHubを経由する設計なので、GitHubが落ちるとpushも止まります。障害時のpush先が欲しいなら、この記事のようにCursorホストのリポジトリを別remoteで持つ形になります。なお公式ドキュメントには Detach from GitHub があり、同期を切ってOriginコピーをスタンドアロンのOriginホストリポジトリへ変換できます。GitHubの長期障害や移行の最終手段として、ミラー→切り離しという経路は一応用意されています（未検証です）。
それでも避難できるのはrepo層だけです。IssueもPull Requestの議論もCIもフェイルオーバーしません。Origin自体の稼働実績もまだ無く、SLAも公開されていません。今日の時点で言えるのは、push先がもう一つあると共有が止まる時間を減らせる、増やす手間は1コマンド、というところまでです。
Cursorは、Originをエージェントが大量にclone、branch、commitする負荷を前提に設計したと言っています。その負荷に耐える設計は、止まらない設計と重なるはずです。GitHubが止まるたびに仕事が止まるのは、ホスティングが一社に集まりすぎた結果でもあります。そこに別の選択肢が育つこと自体に、自分は価値を感じます。
今のところ、自分はどう使うか
自分はGitHubを正本のままにしています。公開もCIも既存のPull RequestもGitHub側にあり、OriginはCursor用の控えと、GitHubが止まった夜の避難先です。正本を移すかどうかは、Originの稼働実績が見えてからで十分です。
載せること自体は難しくありません。先に知っておくと無駄が少ないのは、公開できないことと、origin というremote名が衝突すること。この2つを踏まえたうえで、後編ではchangeモデルとremote名の罠を書きます。
後編はこちら: https://qiita.com/Kinopee/items/747de22525344a796eed