feat: authenticate all ocman-to-OpenCode traffic #377

New issue

Closed

opened 2026-07-18 00:16:27 +02:00 by dries · 0 comments

dries commented

2026-07-18 00:16:27 +02:00

Owner

Parent

#375

What to build

Allow ocman-managed OpenCode servers to require OPENCODE_SERVER_PASSWORD without breaking any session feature. Authentication must be injected at launch and applied consistently by every HTTP and SSE client, including code paths that currently construct OpenCode requests independently.

The secret must not be returned to the browser, written to logs, exposed in runtime diagnostics, or persisted in plaintext unless a reviewed secret-storage mechanism is used. Native mode must remain usable when authentication is disabled.

Acceptance criteria

Ocman can generate or receive a per-host managed OpenCode API secret and inject it into launched instances.
Normal reads and mutations, session creation, ownership probes, catalog calls, and shell/command operations authenticate successfully.
Browser-proxied SSE, headless watcher SSE, autoapprove judge calls, permission/question operations, and health checks authenticate successfully.
Authentication failures are distinguishable from an unreachable instance in logs and user-facing diagnostics without exposing the secret.
The secret is never sent to the frontend or included in structured logs, errors, traces, command previews, or runtime inspection output.
Authentication-disabled native instances continue to work.
Tests exercise authenticated and unauthenticated HTTP/SSE paths, invalid credentials, and secret redaction.
Configuration documentation explains secret precedence and rotation behavior.

Blocked by

None - can start immediately.

## Parent #375 ## What to build Allow ocman-managed OpenCode servers to require `OPENCODE_SERVER_PASSWORD` without breaking any session feature. Authentication must be injected at launch and applied consistently by every HTTP and SSE client, including code paths that currently construct OpenCode requests independently. The secret must not be returned to the browser, written to logs, exposed in runtime diagnostics, or persisted in plaintext unless a reviewed secret-storage mechanism is used. Native mode must remain usable when authentication is disabled. ## Acceptance criteria - [ ] Ocman can generate or receive a per-host managed OpenCode API secret and inject it into launched instances. - [ ] Normal reads and mutations, session creation, ownership probes, catalog calls, and shell/command operations authenticate successfully. - [ ] Browser-proxied SSE, headless watcher SSE, autoapprove judge calls, permission/question operations, and health checks authenticate successfully. - [ ] Authentication failures are distinguishable from an unreachable instance in logs and user-facing diagnostics without exposing the secret. - [ ] The secret is never sent to the frontend or included in structured logs, errors, traces, command previews, or runtime inspection output. - [ ] Authentication-disabled native instances continue to work. - [ ] Tests exercise authenticated and unauthenticated HTTP/SSE paths, invalid credentials, and secret redaction. - [ ] Configuration documentation explains secret precedence and rotation behavior. ## Blocked by None - can start immediately.