feat(core): add server.enabled config option to restore HTTP server

[rmk40]

Summary

Adds a server.enabled config option and --enable-server CLI flag that explicitly enable the HTTP server for the TUI, restoring the pre-982b71e behavior for users who need external connections (desktop app, SDK, etc).

Fixes #8561

Usage

Config (opencode.json):

{
  "server": {
    "enabled": true
  }
}

CLI:

opencode --enable-server

Both use the default port-0 fallback (try 4096, then random) on 127.0.0.1 — the same resilient behavior as before the server was disabled by default.

Changes

• config.ts: Add enabled: z.boolean().optional() to Server schema
• network.ts: Add --enable-server CLI option, resolve enabled from CLI flag or config, return in resolveNetworkOptions()
• thread.ts: Add networkOpts.enabled || to shouldStartServer condition

Why

Since 982b71e ("disable server unless explicitly opted in"), users who need the HTTP server have no clean way to enable it:

• port: 0 fails (schema rejects non-positive)
• hostname: "127.0.0.1" doesn't trigger server (matches default)
• mdns: true works but has unwanted side effects
• There was no config-only path to start the server on default host/port

This provides a clear, self-documenting opt-in via both config and CLI with no side effects.

Testing

Tested locally — setting "server": { "enabled": true } in opencode.json or passing --enable-server correctly starts the HTTP server with the default port-0 fallback behavior.

[github-actions]

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

No duplicate PRs found

[escaton]

Hi @rmk40 are there any blockers to merge this?

[rmk40]

Shouldn't be and I've confirmed there's no way to replicate the desired behavior (which was also prior behavior) of starting the server on localhost, assigning port to 4096 and falling back to dynamic assignment. Basically it takes specifying port to get the server to start on localhost, which will fail if the port isn't available. Yet, starting on say 0.0.0.0 without specifying port works and will try 4096 and fall back to others accordingly.

[rmk40]

Worth noting for anyone evaluating workarounds: --hostname and --hostname 127.0.0.1 on the CLI do start the server today, because shouldStartServer includes a raw process.argv.includes("--hostname") check that fires regardless of the value passed.

The gap this PR addresses is the config-only path. If you set "server": { "hostname": "127.0.0.1" } in opencode.json (no CLI flag), the server won't start because:

• process.argv.includes("--hostname") → false (no CLI flag present)
• networkOpts.hostname !== "127.0.0.1" → false (matches default)

There's no config-only way to say "start the server on the default host/port" without side effects like enabling mDNS or binding to 0.0.0.0. That's what server.enabled (and the new --enable-server CLI flag) provide — a clear opt-in with no side effects, using the same resilient port-0 fallback (try 4096, then random).