f3c54df283
Closes #261 ## Summary - improve startup remote URL selection when the server binds to `0.0.0.0` - print additional reachable remote URLs instead of advertising only the first external address - add targeted tests for address ordering and advertisability behavior ## Problem When CodeNomad was started with `--host 0.0.0.0`, the CLI chose the first external IPv4 address it discovered and displayed only that one as the remote URL. On Windows machines with WSL, Hyper-V, Docker, or other virtual adapters, that often surfaced a virtual `172.x.x.x` address even though a more useful LAN address such as `192.168.x.x` was also reachable and usable from other devices. That made remote access look broken or confusing even though the server itself was accessible. ## What changed - reuse the resolved network-address list for both: - primary remote URL selection - startup logging of additional reachable URLs - choose the primary remote URL from the **advertisable** external addresses instead of any external address - print `Other Accessible URLs` when multiple useful remote URLs are available - avoid hard-coding a preference like `192.168 > 10 > 172` - suppress link-local `169.254.*` addresses from user-facing advertised URLs - add tests covering: - stable ordering across RFC1918 address ranges - link-local addresses being non-advertisable - link-local-first discovery not stealing the primary LAN URL ## Why this approach This keeps address derivation in the network-address resolver layer and limits `index.ts` to startup wiring and presentation. It also fixes the misleading terminal output without redesigning binding behavior, TLS behavior, or the server API contract. ## Validation - `npm run typecheck --workspace @neuralnomads/codenomad` - `npx tsx --test '.\\src\\server\\__tests__\\network-addresses.test.ts'` ## Notes - this change is intentionally focused on selection and presentation of reachable addresses - it does not attempt a broader virtual-adapter classification policy beyond suppressing clearly low-value link-local addresses in user-facing output --------- Co-authored-by: Shantur Rathore <i@shantur.com>
CodeNomad UI
This package contains the frontend user interface for CodeNomad, built with SolidJS and Tailwind CSS.
Overview
The UI is designed to be a high-performance, low-latency cockpit for managing OpenCode sessions. It connects to the CodeNomad server (either running locally via CLI or embedded in the Electron app).
Features
- SolidJS: Fine-grained reactivity for high performance.
- Tailwind CSS: Utility-first styling for rapid development.
- Vite: Fast build tool and dev server.
Development
To run the UI in standalone mode (connected to a running server):
npm run dev
This starts the Vite dev server at http://localhost:3000.
Building
To build the production assets:
npm run build
The output will be generated in the dist directory, which is then consumed by the Server or Electron app.
Debug Logging
The UI now routes all logging through a lightweight wrapper around debug. The logger exposes four namespaces that can be toggled at runtime:
sse– Server-sent event transport and handlersapi– HTTP/API calls and workspace lifecyclesession– Session/model state, prompt handling, tool callsactions– User-driven interactions in UI components
You can enable or disable namespaces from DevTools (in dev or production builds) via the global window.codenomadLogger helpers:
window.codenomadLogger?.listLoggerNamespaces() // => [{ name: "sse", enabled: false }, ...]
window.codenomadLogger?.enableLogger("sse") // turn on SSE logs
window.codenomadLogger?.disableLogger("sse") // turn them off again
window.codenomadLogger?.enableAllLoggers() // optional helper
Enabled namespaces are persisted in localStorage under opencode:logger:namespaces, so your preference survives reloads.