NovaScale
NovaScale 選單

常見問題

與官方 Tailscale 客戶端有何不同?

NovaScale 使用的是改造版 libtailscale,並在應用內直接建立 Tailnet 通信,因此在此場景下無需申請 iOS 系統 VPN 權限。

參考資料:https://tailscale.com/kb/1112/userspace-networking

為何在將 NovaScale 放到背景後,某些情況 SSH 會話仍可恢復?
NovaScale 某些場景依賴 userspace 網路行為與記憶體中的會話狀態。若 iOS 因記憶體壓力終止進程,當前會話將無法恢復。
升級至 NovaScale 1.6.0 後,為什麼會提示 SSH 主機金鑰不相符?

NovaScale 1.6.0 重構了 SSH 通訊基礎。NovaScale 1.5.0 儲存的部分受信任主機金鑰採用較舊的表示格式,因此升級後首次重新連線時,1.6.0 可能會將未變更的主機金鑰顯示為不相符。在 1.6.0 中首次信任的主機不受影響。

移除已儲存的主機金鑰前,請先確認連線的確實是預期主機,並與從伺服器本機或管理員處取得的指紋進行核對。然後前往 更多 > 主機金鑰,找到受影響的主機,向左滑動並選擇 移除。重新連線後,請核對新顯示的指紋,確認一致後再信任。通常只需移除受影響的項目,無需使用 清除全部。

為何在開啟某些 VPN App 後 NovaScale 無法載入主機清單?

部分 VPN App 會啟用 FakeIP 功能,對 DNS 查詢回傳保留 IP 空間中的位址。

NovaScale 的底層基於 Tailscale 內核組網,會直接綁定到用戶的非 VPN 介面(例如 5G 或 Wi‑Fi)並從該介面發起請求。

NovaScale 1.6.0 已針對這些 VPN App 常用的 FakeIP 位址範圍加入緩解措施。大多數使用者不再需要修改 VPN 設定。如果開啟 VPN 時 NovaScale 能正常載入主機,無需進行任何操作。

部分 VPN App 允許使用不同或自訂的 FakeIP 位址範圍。如果該範圍未被 NovaScale 識別,Tailscale 相關網域或自建 Headscale 驗證網域仍可能回傳 FakeIP,導致請求失敗。此時需在 VPN App 中將這些網域設定為回傳真實 IP。

以 Surge 為例,若使用官方 Tailnet 驗證端點,可在 [General] 中加入:

[General]
always-real-ip = *.tailscale.com

若使用自建 Headscale 控制伺服器,還需加入其驗證網域。其他 VPN App 中對應的設定可能稱為「真實 IP」、「FakeIP 過濾」或「排除 FakeIP」。修改後請重新連接 VPN,並重新啟動 NovaScale。

NovaScale、Codex CLI 與 Codex 桌面 App 之間會共享哪些 Codex 狀態?

這些用戶端可以讀取主機上由 Codex 管理的同一份狀態。執行緒識別與名稱、對話記錄和已完成回合、最新模型與思考強度,以及 Goal 狀態會由 Codex 持久化,並可由其他用戶端還原。

即時狀態的邊界不同。正在執行的回合、待處理的核准、目前權限選擇、沙盒與核准原則可能僅屬於發起它們的 Codex 執行環境。NovaScale 無法總是從獨立的 CLI 或桌面 App 執行環境接管這些工作。在 NovaScale 中選擇的權限僅適用於從 NovaScale 發起的回合,不會改變其他用戶端的目前工作階段。

NovaScale Pro 的 iCloud 同步會在你的 Apple 裝置之間同步 NovaScale 的 Codex 主機項目。Codex 對話記錄、原始碼或工作區資料不會上傳到 iCloud;這些資料仍保留在 Codex 主機上。

為什麼 Codex 的模型與思考強度通常能在不同用戶端之間保持一致?

Codex 會將最新模型與思考強度持久化為執行緒中繼資料。當 NovaScale、Codex CLI 或其他 app-server 用戶端在沒有明確覆寫設定的情況下恢復執行緒時,Codex 會還原這些值。用戶端也可以主動選擇其他值,此時明確設定優先。

NovaScale 不會維護固定的模型清單,而是從該主機上的 Codex app-server 取得可用模型與思考強度。因此,選項可能隨 Codex 版本、帳戶、伺服器分階段發布與主機設定而變化。如果更新 Codex CLI 後仍未出現新模型,請使用 NovaScale 的主機維護診斷,並依提示重新啟動或更新 NovaScale Codex 主機服務。

參考資料:https://learn.chatgpt.com/docs/app-server

為什麼 Codex 0.147 提示該執行緒已有作用中的寫入端?

Codex 會將每個執行緒儲存在持久化的 rollout 檔案中。Codex 0.147 對該檔案套用單一寫入端保護:如果 Codex CLI、Codex 桌面 App 或其他 app-server 執行環境仍擁有該執行緒,NovaScale 可以讀取其已持久化的記錄,但傳送新回合可能會被阻止。即使另一個用戶端的最新回合已完成,只要該工作階段仍開啟著執行緒,也可能出現此情況。

NovaScale 不會強制接管,也不會直接修改 rollout 檔案。出現衝突時,NovaScale 提供以下選擇:

  • 結束或關閉目前擁有該執行緒的工作階段,然後在 NovaScale 中選擇再試一次。
  • 等候擁有權到期後重試。對 Codex 0.147 的測試中,未繼續寫入的擁有權會在約 30 分鐘後釋放;如果原用戶端又發起新回合,則會重新開始一輪等候週期。
  • 選擇新工作階段,在同一工作區中獨立開始。
  • 選擇分支執行緒,保留現有記錄並在獨立執行緒中繼續。

app-server 協定仍處於實驗階段,因此後續 Codex 版本可能調整具體的擁有權逾時時間。

參考資料:https://learn.chatgpt.com/docs/app-server