Expose a deliberate local-service route for standalone AOS launches #922

New issue

Closed

opened 2026-08-06 03:44:31 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-06 03:44:31 +00:00

Owner

Problem

A standalone AOS launch can start a local HTTP service successfully, but the surrounding user experience does not provide a corresponding, discoverable way to open that service in the user's browser.

During local corpus-review work, the service was reachable from inside the workspace on both loopback and the container address, yet the browser outside the workspace had no usable route. This makes a normal "run a local review UI" workflow look hung even though the process is healthy.

AOS is intended to feel close to acompose and native workspace operation. Capability parity needs to include an intentional answer for user-facing local services, or a clear, actionable boundary when the host cannot support them.

Desired outcome

Define the standalone AOS contract for locally hosted HTTP services.
Provide a secure, explicit, discoverable route when the host supports browser access, such as controlled port forwarding or an authenticated local-service proxy.
Fail clearly when the host cannot provide that route, including the service URL and the capability that is unavailable.
Preserve the existing default of no ambient public ingress. Private corpus data must not become externally reachable by default.
Document the equivalent native/acompose workflow and test the supported launch path.

Acceptance signals

An agent can launch a loopback-bound review service and give Kai a URL that works from her browser on supported hosts.
Unsupported hosted environments report the missing browser-routing capability promptly, rather than leaving the page loading indefinitely.
The mechanism is opt-in, least-exposed, and suitable for private local-data tools.

## Problem A standalone AOS launch can start a local HTTP service successfully, but the surrounding user experience does not provide a corresponding, discoverable way to open that service in the user's browser. During local corpus-review work, the service was reachable from inside the workspace on both loopback and the container address, yet the browser outside the workspace had no usable route. This makes a normal "run a local review UI" workflow look hung even though the process is healthy. AOS is intended to feel close to `acompose` and native workspace operation. Capability parity needs to include an intentional answer for user-facing local services, or a clear, actionable boundary when the host cannot support them. ## Desired outcome * Define the standalone AOS contract for locally hosted HTTP services. * Provide a secure, explicit, discoverable route when the host supports browser access, such as controlled port forwarding or an authenticated local-service proxy. * Fail clearly when the host cannot provide that route, including the service URL and the capability that is unavailable. * Preserve the existing default of no ambient public ingress. Private corpus data must not become externally reachable by default. * Document the equivalent native/acompose workflow and test the supported launch path. ## Acceptance signals * An agent can launch a loopback-bound review service and give Kai a URL that works from her browser on supported hosts. * Unsupported hosted environments report the missing browser-routing capability promptly, rather than leaving the page loading indefinitely. * The mechanism is opt-in, least-exposed, and suitable for private local-data tools.

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-06 05:44:08 +00:00

Expose standalone local service routes #936