fix(desktop): make dev server port configuration more flexible

[aspiers]

Without this patch, the desktop application requires a strict port configuration (port 1420) and hardcodes the devUrl in tauri.conf.json. This causes issues when the port is already in use during development.

This is a problem because developers cannot easily run multiple instances or work around port conflicts without manual configuration changes.

This patch solves the problem by removing the hardcoded devUrl from tauri.conf.json, setting strictPort to false in vite.config.ts to allow Vite to find an available port, and updating the Rust code to read the dev URL from the Tauri config or fall back to the default localhost:1420.

Closes #6943.

[github-actions[bot]]

The following comment was made by an LLM, it may be inaccurate:

Results

No duplicate PRs found (beyond the PR itself at #6947).

The searches across multiple relevant keyword combinations returned only the PR itself. This suggests that:

1. No other open PRs are currently addressing the same dev server port configuration issue
2. The specific problem (port 1420 conflicts in the Tauri desktop app) hasn't been tackled by another PR
3. The fixes (removing hardcoded devUrl, setting strictPort to false) are unique to this PR

This is a good sign — you can proceed with this PR without worrying about duplicate efforts.

[adamdotdevin]

cc @Brendonovich can you take a look? i like the idea of this, i've had this bite me running multiple

[aspiers]

Rebasing to fix conflicts now...

[Brendonovich]

If Vite decides to use a port other than 1420, how does Tauri become aware of that? I don't think this change implements that. Might be easier to just hardcode a different port number.

[aspiers]

@Brendonovich wrote:

If Vite decides to use a port other than 1420, how does Tauri become aware of that? I don't think this change implements that.

It does! I tested it and it works.

Might be easier to just hardcode a different port number.

Easier but substantially less useful; then you still can't run multiple instances and might get other conflicts on that same port.

[Brendonovich]

@aspiers Can you detail how you've tested this? I ran bun tauri dev in two terminals and both windows loaded localhost:1430 - Tauri's default. Vite was running on 1420 and 1421 but not being used by either instance.

[aspiers]

@Brendonovich I've tested it in three ways:

1. Test it works as normal with no other Tauri app running

Self-explanatory

2. Test conflict with other Tauri app already running

1. Run Whispering, confirm it takes port 1420
2. Run OpenCode Desktop, confirm it takes port 1421 and that the UI launches correctly

3. Test multiple OpenCode Desktop instances running at the same time

Following on from test 2 above:

3. Run OpenCode Desktop again, confirm it takes port 1422 and that another UI launches correctly

[aspiers]

@Brendonovich If it's not working for you on this PR branch, then I would make a wildly uninformed guess as a Tauri / OpenCode newb that maybe you're missing a build step? E.g. see https://github.com/anomalyco/opencode/issues/6780#issuecomment-3710473302.

[Brendonovich]

Ah I think I know why it's working for you: Tauri's behaviour when devUrl isn't provided is to serve assets from frontendDist on its own dev server at localhost:1430. It's likely that you've built the app before and Tauri is serving those assets, rather than connecting to the Vite servers. The thing to check is location.href in the inspector's console - the OC server URL is injected into the webview differently such that it will work in either case.

[aspiers]

Not sure I follow but if I spin up two instances then location.href in the console of the first shows port 1430, and the second shows 1431:

[Brendonovich]

Ok yeah that's what I expected - the webviews aren't connecting to the vite instances, theyre connecting to Tauri's internal dev server that's serving files from desktop/dist. If you delete that folder then it'll stop working. Tauri doesn't have a way to know about the random port that Vite selects

[aspiers]

Ah, I see, thanks. Couldn't we make it dynamically set TAURI_CLI_PORT to the port selected by vite?

[Brendonovich]

Afaik no since 1) TAURI_CLI_PORT sets the port that Tauri's devserver would be started on which would conflict with Vite's and 2) the Tauri CLI is responsible for invoking Vite, without a way for pulling the port number back out.