Sign up
View stargazersSign up

[Bug]: Swift iOS app ignores "Add project starts in" and always browses from ~/#16507

openedOct 6, 2026byBben-vargas

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/mobile

Steps to reproduce

  1. On a desktop host, open Settings → General, choose All environments, and set Add project starts in to ~/projects.
  2. Confirm the value is saved on the server: ~/.t3/userdata/settings.json contains "addProjectBaseDirectory": "~/projects".
  3. On iPhone, open the Swift app (TestFlight) connected to that environment.
  4. Start Add project and pick an existing folder or clone a repository.

Expected behavior

The folder browser and clone destination start in ~/projects, the same as web and desktop. The React Native app does this too (apps/mobile/src/features/projects/AddProjectScreen.tsx:408 reads config?.settings.addProjectBaseDirectory).

Actual behavior

The Swift app always starts in ~/, whatever the setting is.

On t3code/rebuild-mobile-app-swift @ 8ad853cf1e, apps/swift-ios/Features/Workspace/ProjectAndArchiveViews.swift hard-codes the starting paths in AddProjectView and never reads addProjectBaseDirectory. That key does not appear anywhere under apps/swift-ios.

  • L36 @State private var localPath = "~/"
  • L39 @State private var destinationPath = "~/"
  • L47 @State private var browsePath = "~/"
  • L626 resetEnvironmentState() resets browsePath = "~/"
  • L639–642 resets localPath and builds the clone destination from "~/"

The setting is stored per environment, so the fix is probably to seed these paths from the selected environment's server settings, fall back to ~/ when the setting is empty, and reseed on environment switch in resetEnvironmentState().

This is separate from #14960. That issue covers Create New Project always using ~/.t3/projects on every client. This one covers the Swift app's Add project folder and clone starting path.

Impact

Minor bug or occasional failure

Version or commit

Swift app: TestFlight 0.1.0 (57) (code reference: t3code/rebuild-mobile-app-swift @ 8ad853cf1e). Servers: 0.0.46-nightly.20261005.2702.

Environment

iOS 27.0.1, iPhone. Three macOS hosts running the Nightly desktop app, connected over Tailscale HTTPS.

Logs or stack traces

None. No error is shown, the setting just isn't read.

Workaround

Navigate to ~/projects by hand in the browser each time, or add projects from the desktop or web app, which honor the setting.

This report was investigated and drafted with an AI coding agent (Claude Opus 5.5 in T3 Code). I reproduced the behavior on my iPhone and reviewed the report.

JJulius MarmingeOct 6, 2026

Note

Grok responding on behalf of Julius.

Triage

Thanks @ben-vargas for the precise report and line references, they made this easy to verify. t3code/rebuild-mobile-app-swift is still at 8ad853cf1e, the commit you cited, and addProjectBaseDirectory doesn't appear anywhere under apps/swift-ios.

What I found

  • The server already sends the setting. Add project starts in is the folder the Add Project browser opens in (empty means ~/). Web and desktop read it from the environment's server settings in the command palette, and the React Native app does the same. server.getConfig includes settings, and client redaction copies this field through.
  • The Swift app drops it before the sheet sees it. ServerSettingsSnapshot decodes a fixed key list that doesn't include addProjectBaseDirectory, so the value is discarded. FeatureEnvironment is what Add Project reads, and mapEnvironment copies newProjectsRoot onto it but not this path.
  • The sheet hard-codes the start. localPath, destinationPath, and browsePath are initialized to ~/, and resetEnvironmentState() sets them back to ~/ on every environment change, including the clone destination. That matches what you see: Folder and Clone always open at ~/ on every environment.
  • New mode is separate. New already uses newProjectsRoot; where those projects are created is #14960.

Code references: Swift app at 8ad853cf1e: ProjectAndArchiveViews.swift, resetEnvironmentState, ServerSettingsSnapshot, mapEnvironment. Other clients on main at ac8e9453ca: getAddProjectInitialQuery, CommandPalette.tsx, AddProjectScreen.tsx.

Likely fix area

apps/swift-ios on t3code/rebuild-mobile-app-swift (the Swift app isn't on main). One option: decode addProjectBaseDirectory in ServerSettingsSnapshot, carry it on FeatureEnvironment next to newProjectsRoot, and seed the folder path, browser path, and clone destination parent from it when the sheet opens and when the environment changes, trimming it and falling back to ~/ when missing or blank, like getAddProjectInitialQuery.

A maintainer will decide on the fix direction.

JJulius Marminge15d ago

Classified as a Swift iOS bug; no duplicate found in the open-issue scan for “Add project”, “starts in”, and Swift/folder/clone destination reports.

Verification is blocked on current main, a12d6ed942: that checkout contains the React Native client but no apps/swift-ios. The Swift project is on the separate t3code/rebuild-mobile-app-swift branch. I did not reproduce the behavior in a running Swift app. The EAS preflight in the fresh mobile checkout failed resolving expo-asset; no simulator session was started.

Does this still happen in the latest Swift TestFlight build? Please include its build number and whether both the existing-folder browser and clone destination ignore the setting after switching environments. That will identify the Swift revision to verify rather than testing the React Native client on main.

JJulius Marminge15d ago

Fresh triage: no duplicate found in 947 open issues. On Linux, ran an isolated dev server at b5a226e49c: server.getConfig returns the configured starting directory, and filesystem.browse resolves that directory correctly. Sending ~/ instead browses the host home, matching the Swift client's hard-coded request. Runtime transcript.

The Swift client at build 62 drops this setting during config decoding and hard-codes the paths in AddProjectView.resetEnvironmentState(). #23211 carries the per-environment setting through to folder and clone paths, including delayed settings. Both final code reviewers returned MERGE. Native build and interaction verification remain cannot-verify ios-swift: this VM has no Xcode. The PR lists every missing native proof row. No additional reporter information is needed; removed the stale needs-more-info label.