anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Add server.enabled config option to explicitly enable HTTP server #5956

New Issue
Open
opened 2026-02-16 17:58:47 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 17:58:47 -05:00
Owner
Copy Link
Copy Source

Originally created by @rmk40 on GitHub (Jan 14, 2026).

Originally assigned to: @thdxr on GitHub.

Problem

Since v1.1.10 (commit 982b71e86), the TUI no longer starts an HTTP server by default. While this is a reasonable security improvement, it breaks workflows that depend on the HTTP server:

  • Desktop app connecting to the TUI backend
  • SDK integrations that communicate via HTTP
  • Remote access scenarios (e.g., driving OpenCode from a mobile app)

Current Workarounds Don't Work Well

  1. port: 0 - Fails because the schema uses .positive() which rejects 0
  2. hostname: "127.0.0.1" - Doesn't trigger server because it matches the default
  3. mdns: true - Works but enables mDNS discovery which may not be desired

Users need a clear, explicit way to opt into the HTTP server without side effects.

Proposed Solution

Add a server.enabled config option:

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

This provides a clear opt-in mechanism that:

  • Is self-documenting (the intent is obvious)
  • Has no side effects (unlike mdns: true)
  • Restores pre-982b71e behavior for users who need it

Implementation

Minimal 3-file change:

  1. Add enabled: z.boolean().optional() to Server schema
  2. Return enabled from resolveNetworkOptions()
  3. Add networkOpts.enabled || to shouldStartServer condition

I have a PR ready with this implementation.

References

Originally created by @rmk40 on GitHub (Jan 14, 2026). Originally assigned to: @thdxr on GitHub. ## Problem Since v1.1.10 (commit 982b71e86), the TUI no longer starts an HTTP server by default. While this is a reasonable security improvement, it breaks workflows that depend on the HTTP server: - **Desktop app** connecting to the TUI backend - **SDK integrations** that communicate via HTTP - **Remote access** scenarios (e.g., driving OpenCode from a mobile app) ### Current Workarounds Don't Work Well 1. **`port: 0`** - Fails because the schema uses `.positive()` which rejects 0 2. **`hostname: "127.0.0.1"`** - Doesn't trigger server because it matches the default 3. **`mdns: true`** - Works but enables mDNS discovery which may not be desired Users need a clear, explicit way to opt into the HTTP server without side effects. ## Proposed Solution Add a `server.enabled` config option: ```json { "server": { "enabled": true } } ``` This provides a clear opt-in mechanism that: - Is self-documenting (the intent is obvious) - Has no side effects (unlike `mdns: true`) - Restores pre-982b71e behavior for users who need it ## Implementation Minimal 3-file change: 1. Add `enabled: z.boolean().optional()` to Server schema 2. Return `enabled` from `resolveNetworkOptions()` 3. Add `networkOpts.enabled ||` to `shouldStartServer` condition I have a PR ready with this implementation. ## References - Commit that disabled server by default: 982b71e861e538c33382ae34049f312f46f37cd2 - Related PR: #7529
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#5956
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?