[leehom0123]

Summary

• Setting CODEG_STATIC_DIR to a directory containing index.html makes the desktop Tauri window load from the built-in HTTP server (which serves that dir) instead of the embedded frontend assets
• The web server is force-started when the env var is set, even if auto_start is off in the persisted config
• Lets pnpm build + restart pick up UI changes without recompiling Rust

Test plan

• Set CODEG_STATIC_DIR=D:\repos\agent-app\codeg\out and launch codeg.exe — the desktop window should load from the external dir (check the log line [WEB] Desktop window loading from external dir: ...)
• Modify a frontend file, pnpm build, restart codeg.exe — the change appears without rebuilding Rust
• Unset CODEG_STATIC_DIR — the app falls back to embedded assets as before
• cargo check --no-default-features --bin codeg-server still compiles cleanly (no dead-code warning)

https://github.com/xintaofei/codeg/issues/

[dawNotPoi]

I traced the external-window startup path against CodeG's Tauri capabilities and web-server state. Two issues appear to block the advertised desktop behavior; details are inline. I could not run a native desktop window from this environment, so the review is based on the current source and Tauri's documented origin rules.

[dawNotPoi]

This changes main from the bundled app origin to http://127.0.0.1, but neither capabilities/default.json nor desktop.json grants that external origin via remote.urls. Tauri v2 grants API access to remote pages only when explicitly configured (https://v2.tauri.app/security/capabilities/); CodeG's main window still relies on Tauri commands/plugins for desktop behavior. At this URL those IPC calls are denied, so loading the HTML is insufficient to make the desktop app work. Please keep the custom assets under the app origin, or add a narrowly scoped remote capability and verify the main window's IPC calls on a packaged desktop build.

[leehom0123]

Fixed in e0a0ef2. Both capability files now grant the external origin via remote.urls: ["http://127.0.0.1:*"], so core/plugin APIs stay available when main loads the served page. Two notes: (1) Tauri 2.9's remote config supports only urls — no per-window scoping — and the port follows the web-service config, so it cannot be pinned narrower than 127.0.0.1:*; the capability therefore also applies to any other page served from a local port that opens in a codeg window. (2) I verified at source level plus unit tests; a packaged-desktop smoke run of the external-dir path is still on my list.

[dawNotPoi]

The force-start at lines 1123-1141 only logs an error. If binding the configured port fails (or loading the web-service config fails), WebServerState.port remains at its initial 0, yet this branch still builds http://127.0.0.1:0/... because CODEG_STATIC_DIR is valid. The desktop window then opens an unreachable page instead of the bundled UI. Please select the external URL only from a successful server start with a valid returned port; on failure, fall back to the app URL or show an actionable startup error. A port-collision regression case would cover this path.

[leehom0123]

Fixed in e0a0ef2. The window URL is now built by resolve_main_window_url: the external http://127.0.0.1:{port} origin is used only when running_port > 0, i.e. after a successful bind; on a failed bind (or an unparseable URL) the window falls back to WebviewUrl::App with an error log saying why, and the CODEG_STATIC_DIR force-start failure now also raises the same system notification as the auto-start path. Added unit tests covering the port-collision case (port 0 → bundled app URL) plus the live-port, normalization, and no-external-dir paths. cargo check, cargo clippy --all-targets and the new tests pass; the packaged port-collision scenario itself has not been run in a built app yet.

[dawNotPoi]

Re-reviewed the current head, ad27199. It is unchanged from my September 25 review, and both existing findings remain unresolved:

1. The main window loads an external http://127.0.0.1 origin, but neither capability file grants that origin through remote.urls, and tauri.conf.json adds no such capability. Core/plugin APIs protected by those capabilities remain unavailable to this page. Please preserve the app origin or configure narrowly scoped remote access and verify desktop functionality in a packaged build. See #829 (comment) and https://v2.tauri.app/security/capabilities/#remote-api-access.
2. WebServerState.port starts at 0. A failed listener bind returns before a successful start records the port; startup only logs the failure, while main-window URL selection still depends solely on a valid CODEG_STATIC_DIR. A port collision can therefore open http://127.0.0.1:0/... instead of a usable UI. Please use the external URL only after successful startup, with a fallback or actionable error on failure, and cover the port-collision case. See #829 (comment).

Please address these findings before requesting another review. This is a source-level verification; I have not run the packaged desktop app.

[leehom0123]

Both review findings are addressed in e0a0ef2 (see inline replies). cargo check, clippy --all-targets and 4 new unit tests (desktop mode) pass. Ready for re-review; the packaged-desktop smoke run of the CODEG_STATIC_DIR path is still pending on my side.