Cursor Origin 是 Cursor 提供的 Git 託管服務。把儲存庫放上去、進行審查、再合併。它的角色和 GitHub、GitLab 一樣。官方標語是「A git forge for the agentic era」。它不是以人類一次一個 Pull Request 的速度來設計，而是以代理程式能在短時間內產生大量分支與差異為前提。
Cursor Ambassador 有稍微提早釋出，所以我立刻試用了。而在我撰寫本文的 2026 年 8 月 17 日，初期 Beta 已開始依序提供給所有付費方案。除了管理員選擇退出的企業組織外，只要是付費方案（Pro / Teams / Enterprise）就已經可以使用。採用舊版隱私模式的團隊，在切換到新的隱私模式之前無法啟用。官方文件也已公開。這是把既有 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 都照常可用。
設定只要兩行。不需要 GitHub 的 PAT，也不需要 gh auth。
curl -fsSL https://downloads.cursor.com/origin/install.sh | sh
origin auth loginorigin auth login 會進行認證，並替 origin.cursor.com 設定 git 的 credential helper。之後的 git push / git pull 就不需要手動輸入另一組 token。CLI 支援 macOS 與 Linux（包含 WSL）。原生 Windows 目前還不能用（CLI 文件）。
容易混淆的是，CLI 的名字也叫 origin。它和 git 裡慣例使用的 remote 名稱 origin 是不同東西，請注意分辨。
儲存庫與 Pull Request 的管理，改用 origin 取代 gh。
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 的內容。commit、branch、tag 都會原封不動帶上去。不同的是外圍。
項目GitHubOrigin主機github.comorigin.cursor.com認證GitHub 帳號 / ghCursor 帳號 / origin CLI公開儲存庫可以不行（只有團隊內的 Internal / Private）Issues / Actions / Releases有主機端沒有。CI 需透過 Apps 外掛連接Pull Request新建時通常是 open稱為 change，預設是 draft。具有版本（version）
最讓我驚訝的是不能做公開儲存庫。可見範圍只有兩種：團隊全員都能看見的 Internal，以及只有被允許成員可見的 Private，沒有對網際網路公開的選項。現在還不能當作 OSS 的發布場所。
像 Issues 或 Actions 執行紀錄這類「主機端資料」，不會因為 git push 就跟著移過去。.github/workflows 的 YAML 仍然會留在儲存庫中，但不代表 Origin 上會執行 GitHub Actions。CI 是透過名為 Apps 的機制，串接外部服務（Buildkite、Depot、Vercel）。
Pull Request 雖然外觀很接近，但內部模型不同。Origin 的單位是稱為 change、帶有版本（version）的差異集。GitHub 的 Pull Request 會隨著 commit 累積而內容持續變動。當代理程式在短時間內反覆修正時，審查者就得追著不斷變動的 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% 的 workflow 因基礎設施因素失敗。這是連 GitHub 自己都在每月可用性報告裡寫成 unacceptable（無法接受）的規模。外部統計則顯示，最近一年被列為 major 的障礙有 48 件。自 2025 年 12 月以來，發生頻率還提高了。
git 是分散式的，所以本機上的 commit 在障礙期間仍然可以繼續進行。停住的是匯集到主機的部分，也就是共享、審查與 CI。當有兩個 remote 時，可以把其中的共享先導走。即使 GitHub 那邊掛掉了，git push cursor main 還是能成功，其他機器或團隊成員也能從 Origin 做 pull。這次我在 GitHub 回報 Pull Requests 劣化時，正好把 main push 到 Origin。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 目的地，可以減少共享停擺的時間，而且增加這個備援只要一條指令。
Cursor 表示，Origin 的設計是以代理程式會大量 clone、branch、commit 的負載為前提。能承受那種負載的設計，理應也會和不容易停擺的設計相互重疊。每次 GitHub 出問題就讓工作停擺，根本原因之一也是託管服務過度集中在同一家。對我來說，能多一個選擇這件事本身就很有價值。
目前我會怎麼用
我目前仍然把 GitHub 當正本。公開、CI、既有 Pull Request 都還在 GitHub 端，Origin 只是 Cursor 的備用，以及 GitHub 故障夜晚的避難所。要不要把正本移過去，等 Origin 的實際運作紀錄更清楚後再說也不遲。
要把它加上去本身並不難。先知道可以少踩坑的重點有兩個：不能公開，以及 origin 這個 remote 名稱會衝突。先理解這兩點之後，後篇我會寫 change 模型和 remote 名稱的陷阱。
後篇在這裡：https://qiita.com/Kinopee/items/747de22525344a796eed
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
