Repository navigation
[Bug]: Swift TestFlight app: "Unknown request tag: server.getSettings" on nightly 3814 #26446
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Run a server on
0.1.4-nightly.20261028.3814(Windows 11). - Connect the Swift TestFlight iPhone app (T3 Code SwiftUI 0.1.0 build 68,
com.t3tools.t3code.swiftui, iOS 27.2; user agentT3Code/68 CFNetwork/3896.200.61 Darwin/27.2.0). - Open any thread, with the composer's model picker visible (mine showed Claude Opus 5.5, Build, Medium).
- An alert appears straight away.
Expected behavior
Model preferences load.
Actual behavior
In a thread, an alert appears:
Something went wrong
Unknown request tag: server.getSettings
I've also seen this message for the same problem:
Could not load model preferences. Unknown request tag: server.getSettings
Its other requests succeed in the server traces: session, shell, thread snapshots and the WebSocket upgrade. As far as I remember this worked before the 2026-10-28 nightly, but I haven't tested an older nightly to confirm.
Likely cause: #26238 ("delete 18k lines of code that nothing reaches", 67661cf) removed the RPC:
packages/contracts/src/rpc.ts:- serverGetSettings: "server.getSettings",apps/server/src/ws.ts: removed the handler returningserverSettings.getSettingsredacted for the client
Nightly 3814 (ce66aab) includes that commit; 3796 (b88da91) does not. The RPC is still absent from rpc.ts in nightly 3822 (48a2923) and on main. #26238 changed many apps/mobile files but removed no in-repo caller of this RPC, and the error text isn't in this repo. The installed TestFlight app appears to still call the removed RPC; I haven't established where its source lives.
Possible fixes:
- Restore
server.getSettingsas an alias until TestFlight builds that call it age out, or - Have the Swift client read settings from the
server.getConfigresponse. That returnsServerConfig, whosesettingsfield is the same redactedServerSettingsthe old RPC returned.
Impact
Minor bug or occasional failure
Version or commit
0.1.4-nightly.20261028.3814 (ce66aab)
Environment
Server: T3 Code (Nightly) on Windows 11. Client: T3 Code SwiftUI 0.1.0 (68) from TestFlight, com.t3tools.t3code.swiftui, iOS 27.2, iPhone 16 Pro Max. The regular T3 Code app (2.0.0, build 122) is also installed.
Logs or stack traces
Could not load model preferences. Unknown request tag: server.getSettingsWorkaround
Use the desktop app, which still works on this server.
— Geoff. I'm not a developer; an AI agent (Claude) gathered the evidence from my machine and wrote this, so please flag anything that doesn't add up.
Activity
josephstafki-hub commentedon Oct 30, 2026
Still reproduces on
0.1.6-nightly.20261030.3940, Linux server. It blocks every send from the Swift app, not just model preferences.0.1.6-nightly.20261030.3940(commitae521d1d79), Linux x64, Node v26.12.1.T3Code/68 … Darwin/27.0.0, iOS 27.0.1), connected through T3 Connect.f021c92c),modelValidationConfig()inapps/swift-ios/App/NativeFeatureClient.swiftcallsclient.serverSettings()(that is,server.getSettings) "before dispatch". It is called fromsendMessageResolved,createThread,createThreadAndSendResolvedandrecoverBootstrap, so the removed RPC fails every send and every thread creation. I'd suggest raising the impact above "minor". With nightly ≥3814, the TestFlight app can't send at all.server.getSettingsis absent at thev0.1.6-nightly.20261030.3940tag and onmain. fix(server): SwiftUI iOS app loads model preferences again #26466 / fix(server): Swift TestFlight clients can read settings again #26455 would fix it.Produced by Claude Opus 5.5 (Claude Code agent) via T3 Code triage.
Fannolo commentedon Oct 31, 2026
I’m also experiencing this with the latest Swift iOS TestFlight build available to me, 0.1.0 (68), connecting to T3 Code Nightly 0.1.6-nightly.20261030.3904 on an Apple Silicon Mac mini.
Opening a thread shows:
This confirms the same problem on a macOS host and a later nightly than the original report.
Is there a plan to merge #26455 or #26466, or a recommended workaround for existing TestFlight users?
Fannolo commentedon Oct 31, 2026
The proposed direction is to use
server.getConfigand read itssettingsfield as the common path for fresh settings reads across clients. This keeps settings retrieval consistent with the existing configuration API and the cleanup goal in #26238.PR #28170 brings the Swift app onto that path by migrating all three remaining
server.getSettingscallers. It preserves fresh reads before settings updates and leaves the redundant server endpoint removed. The PR targetst3code/rebuild-mobile-app-swift, the branch behind #5178.There are two separate delivery concerns:
server.getConfig.settings, as fix(swift-ios): read settings from server configuration #28170 does.server.getSettingscould be a temporary compatibility measure, with retirement once those clients are no longer supported. It would not need to remain a second permanent settings API.The PR includes 17 passing core configuration tests and a successful native Swift WebSocket probe against an isolated nightly server. It also documents the Xcode compile limitation that prevented full iOS app testing.
@t3dotgg, since you authored the Swift app PR #5178, could you review #28170 or route it to the appropriate maintainer, and confirm whether this is the intended settings-read path going forward?
thekalyptos commentedon Nov 2, 2026
Reproduced with T3 Code stable 0.1.6 on an Apple Silicon Mac. The current iPhone app shows
Unknown request tag: server.getSettingswhen opening an existing thread and prevents sending. I cleanly restarted the Mac desktop app and its bundled server; the error persisted. The existing thread still opens on desktop. This affects the stable server as well as the nightlies reported above.Update: I tried several older TestFlight builds against the 0.1.6 server and the problem persisted. After switching the Mac desktop app and its bundled server to official stable 0.1.3, I could send a message from the iPhone again. The app was originally reported as TestFlight build 68; I did not record which mobile build was installed for the successful test.
This supports the missing
server.getSettingscompatibility explanation. Before switching the live server, we also tested 0.1.3 against a copy of the existing database: the RPC succeeded and an existing thread could be read. The server warned that the database contained seven newer migrations. I backed up my data before downgrading; this one successful test does not establish that rolling back a newer database is safe or that all newer features remain compatible.gmelvill commentedon Nov 4, 2026
Update: I tested #26455 at
d61d08fde1on my own setup (a Windows 11 host and a physical iPhone running TestFlight build 68). With it,server.getSettingssucceeds, threads open without the alert, and messages send and receive replies. Details are on the PR: #26455AurelienPautet commentedon Nov 4, 2026
Same problem here, also on the latest nightly and on a macOS host.
0.1.8-nightly.20261104.4165, macOS 27.2 (26B123), Apple M4. A second linked machine is on the same version.0.1.0build 68 (com.t3tools.t3code.swiftui), iPhone13,2, iOS 27.2, user agentT3Code/68 CFNetwork/3896.200.61 Darwin/27.2.0.Unknown request tag: server.getSettings. The same thread works from desktop/web against the same server.+1 for restoring
server.getSettingsfor already-installed builds (#26455): the fix is server-side and would unblock existing TestFlight users without waiting for another app build. I'm happy to test a nightly that includes it and report back.