[Bug]: TUI ignores server config (port, hostname, cors) since resolveNetworkOptionsNoConfig call missing config

[GoldJohnKing]

Description

Since v1.4.1+, the TUI no longer reads server.port, server.hostname, server.cors etc. from opencode.json config. This means the HTTP server never starts when configured only via config file (no CLI flags), breaking workflows that depend on external WebUI access (e.g. OpenChamber, browser-based clients).

In packages/opencode/src/cli/cmd/tui/thread.ts line 184:

const network = resolveNetworkOptionsNoConfig(args)

This calls resolveNetworkOptionsNoConfig without passing the config parameter, so config?.server?.hostname, config?.server?.port etc. all resolve to undefined, falling back to CLI defaults (port=0, hostname="127.0.0.1").

The shouldStartServer check then evaluates:

• network.port !== 0 → false
• network.hostname !== "127.0.0.1" → false

Result: the HTTP server is never started, even when opencode.json explicitly configures it.

This worked correctly in v1.4.0, which used resolveNetworkOptions(args) (reads config via Config.Service).

Steps to reproduce

1. Configure ~/.config/opencode/opencode.json with:

   {
     "server": {
       "port": 4096,
       "hostname": "0.0.0.0"
     }
   }

2. Run opencode (TUI mode, no CLI flags)
3. Observe that port 4096 is not listening: curl http://localhost:4096 fails with "Connection refused"
4. ss -tlnp shows no process bound to port 4096

Expected behavior

The TUI should read server.* config from opencode.json and start the HTTP server, as it did in v1.4.0.

Root cause

The regression was introduced when thread.ts was changed from:

const network = await resolveNetworkOptions(args)

to:

const network = resolveNetworkOptionsNoConfig(args)

This was likely an unintended side effect of the CLI perf refactor or the config split PR (#13968).

Workaround

Pass --hostname on the CLI to trigger server startup:

opencode --hostname 0.0.0.0

OpenCode version

v1.4.11

Operating System

WSL2 (Ubuntu 24.04)