FAQ
How does this differ from the official Tailscale client?
NovaScale uses a libtailscale fork and dials tailnet traffic inside the app process, so it does not require iOS VPN permission for this use case.
Reference: https://tailscale.com/kb/1112/userspace-networking
Why can SSH sessions resume after app backgrounding?
Why does NovaScale report an SSH host key mismatch after upgrading to 1.6.0?
NovaScale 1.6.0 rebuilt its SSH transport foundation. Some trusted host keys saved by NovaScale 1.5.0 use an older representation, so 1.6.0 may report an unchanged host key as a mismatch when you first reconnect after upgrading. Hosts first trusted in 1.6.0 are not affected.
Before removing a saved host key, confirm that you are connecting to the expected host and compare its fingerprint with one obtained directly from the server or its administrator. Then open More > Host Keys, find the affected host, swipe left, and choose Remove. Reconnect and verify the displayed fingerprint before trusting it again. You normally only need to remove the affected entry; using Clear All is unnecessary.
Why does NovaScale sometimes fail to load hosts while another VPN app is running?
Some third-party VPN apps enable a feature called FakeIP that returns addresses from a reserved IP space for DNS queries. NovaScale can bind to a non-VPN network interface, such as 5G or Wi-Fi, and send requests from that interface directly.
NovaScale 1.6.0 mitigates the FakeIP ranges commonly used by these VPN apps. Most users no longer need to change their VPN configuration. If NovaScale loads your hosts normally while the VPN is active, no action is required.
Some VPN apps allow a different or custom FakeIP address range. If that range is not recognized by NovaScale, requests for Tailscale domains or your self-hosted Headscale authentication domain can still receive FakeIP addresses and fail. In that case, configure the VPN app to return real IPs for those domains.
In Surge, for example, when using the official Tailnet authentication endpoint, add this line under [General]:
[General]
always-real-ip = *.tailscale.com
For a self-hosted Headscale control server, also add its authentication hostname. Other VPN apps may call the equivalent setting “real IP,” “FakeIP filter,” or “exclude from FakeIP.” Restart the VPN connection and NovaScale after changing it.
What Codex state is shared across NovaScale, Codex CLI, and the Codex desktop app?
These clients can read the same Codex-owned state on your host. Thread identity, name, transcript and completed turns, the latest model and reasoning effort, and goal state are persisted by Codex and can be restored by another client.
Live state has a different boundary. A running turn, pending approval, current permission selection, sandbox, and approval policy can belong only to the Codex runtime that started them. NovaScale cannot always take over that work from a separate CLI or desktop-app runtime. Permission choices made in NovaScale apply to turns started from NovaScale; they do not change another client’s current session.
NovaScale Pro’s iCloud sync carries NovaScale Codex host entries between your Apple devices. It does not upload Codex transcripts, source code, or workspace data to iCloud; that data remains on your Codex host.
Why do the model and reasoning effort usually match across Codex clients?
Codex persists the latest model and reasoning effort as thread metadata. When NovaScale, Codex CLI, or another app-server client resumes the thread without an explicit override, Codex restores those values. A client can intentionally select a different value, and an explicit override takes precedence.
NovaScale obtains the available models and effort levels from the Codex app-server on that host instead of maintaining a fixed list. The choices can therefore vary with your Codex version, account, server rollout, and host configuration. If a newly available model is missing after a Codex CLI update, use NovaScale’s host maintenance diagnostics and restart or update the NovaScale Codex host service as instructed.
Reference: https://learn.chatgpt.com/docs/app-server
Why does Codex 0.147 say this thread already has an active writer?
Codex stores each thread in a durable rollout file. Codex 0.147 applies single-writer protection to this file: if Codex CLI, the Codex desktop app, or another app-server runtime still owns the thread, NovaScale can read its persisted history but may be blocked from sending another turn. This can happen even when the other client’s latest turn has finished but that session still has the thread open.
NovaScale does not force a handoff or edit the rollout file directly. When the conflict appears, NovaScale offers these options:
- Exit or close the session that currently owns the thread, then choose Try Again in NovaScale.
- Wait for the ownership to expire, then retry. In testing with Codex 0.147, an inactive writer was released after about 30 minutes. Starting another turn in the owning client began a new inactivity period.
- Choose New Session to start separately in the same workspace.
- Choose Fork Thread to preserve the existing history while continuing in an independent thread.
The app-server protocol is experimental, so the exact ownership timeout may change in later Codex releases.
Reference: https://learn.chatgpt.com/docs/app-server