Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Feature Request: HTTPS Support for opencode web Command

Problem Description

Currently, the opencode web command only supports HTTP protocol and cannot enable HTTPS directly. This creates inconvenience in the following scenarios:

1. Local development requiring HTTPS: Certain browser APIs (e.g., Clipboard API, Service Workers) require HTTPS environment
2. Enterprise intranet environments: Corporate security policies may mandate HTTPS for all web services
3. Remote access scenarios: HTTPS is a basic security requirement when accessing over the internet
4. Development experience consistency: Maintaining protocol consistency with production environments

Current Behavior

opencode web --port 3000 --hostname 127.0.0.1
# Can only be accessed via http://127.0.0.1:3000

Available network configuration options:

• --port: Listen port
• --hostname: Listen hostname
• --mdns: mDNS service discovery
• --cors: CORS configuration

No HTTPS-related options available

Expected Behavior

I would like the opencode web command to support HTTPS configuration, similar to other development servers (Vite, webpack-dev-server):

# Option 1: Auto-generate self-signed certificate (development)
opencode web --https

# Option 2: Specify certificate files
opencode web --https --cert /path/to/cert.pem --key /path/to/key.pem

# Option 3: Via configuration file
opencode web --config opencode.jsonc

Configuration File Example

{
  "web": {
    "https": true,
    "cert": "/path/to/cert.pem",
    "key": "/path/to/key.pem",
    "port": 3000
  }
}

Current Workarounds

Currently, HTTPS can only be achieved through reverse proxies:

Using Nginx

server {
    listen 443 ssl;
    server_name localhost;
    
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
    }
}

Using Caddy

caddy reverse-proxy --from https://localhost --to localhost:3000

However, these solutions require additional tools and configuration, increasing complexity.

Reference Implementations

HTTPS support in other development tools:

Vite

vite --https
vite --https --cert ./cert.pem --key ./key.pem

webpack-dev-server

devServer: {
  https: true,
  // or
  https: {
    key: fs.readFileSync('/path/to/key.pem'),
    cert: fs.readFileSync('/path/to/cert.pem'),
  }
}

Next.js (via local-ssl-proxy)

npm install -g local-ssl-proxy
local-ssl-proxy --source 3001 --target 3000 --cert localhost.crt --key localhost.key

Suggested Implementation

Phase 1: Basic HTTPS Support

• Add --https flag
• Add --cert and --key parameters
• Support HTTPS options in configuration file

Phase 2: Automatic Certificate Generation (Optional)

• Integrate mkcert or similar tools
• Auto-generate self-signed certificate on first opencode web --https run
• Prompt user to trust the certificate

Phase 3: Advanced Features (Optional)

• HTTP/2 support
• Automatic HTTP to HTTPS redirect
• Let's Encrypt integration (for public deployments)

Use Cases

1. PWA Development: HTTPS required to test Service Workers
2. Clipboard API Testing: navigator.clipboard requires secure context
3. WebRTC Development: Certain WebRTC features require HTTPS
4. Enterprise Intranet Deployment: Meeting corporate security compliance requirements
5. Remote Collaboration: Securely accessing OpenCode Web over the internet

Environment

• Operating System: Linux / Windows / macOS
• OpenCode Version: Output of opencode --version
• Node.js Version: Output of node --version

Additional Context

• This feature would not affect existing HTTP mode, maintaining backward compatibility
• Vite's implementation can be referenced - its HTTPS support is very concise and user-friendly
• HTTP should remain the default, with HTTPS as an optional feature

If this feature would help you too, please upvote 👍 to show support!