Add base path support for the observability dashboard

[akarshghale]

Please add support for hosting the observability dashboard under a configurable base path, for example:

/agent-browser

Current behavior:

• the dashboard appears to assume it is being served from /
• when it is mounted under a subpath, the initial UI shell may load, but the full dashboard does not behave correctly
• in practice, serving it behind a reverse proxy on a path prefix leads to incomplete or broken runtime behavior

What I need is for the dashboard to work correctly when it is not served from /, including:

• static assets resolving under the configured base path
• websocket/API/session/runtime requests using the same base path
• redirects and internal links preserving the base path
• overall dashboard behavior remaining the same as when hosted at root
• A configurable base path would make the dashboard much easier to integrate into existing applications and reverse-proxy setups where the dashboard needs to live under a subpath instead of at the origin root.

It would be helpful if this support included either:

• a runtime/config option for the dashboard base path, or
• documented guidance for how the dashboard is expected to behave behind a reverse proxy on a subpath

[akarshghale]

The dashboard frontend should not hardcode http://localhost:4848. It should derive its API and WebSocket endpoints from same-origin by default, with optional configurable public origin and base-path support for reverse-proxy deployments.

[Travor278]

Hi! I’d be interested in taking a pass at this.

From what I can tell, the dashboard currently works fine when served from /, but starts to break once it’s mounted behind a reverse proxy under a subpath like /agent-browser — especially around API/WebSocket/runtime requests, and possibly static asset resolution too.

My rough plan would be:

1. make the dashboard work cleanly under a configurable base path
2. derive API and WebSocket endpoints from same-origin + base path by default
3. keep the current root-path behavior unchanged
4. only add an explicit public-origin/base-path override if it turns out to be necessary

I’m thinking of starting with a draft PR so it’s easier to discuss concrete changes instead of only talking in the abstract.

If that direction sounds reasonable, I’ll start there.

[akarshghale]

@Travor278 There's already 2 PRs that adds the same-origin, i feel it's better you build on one of those PRs and add base-path support instead:

1. Make dashboard work from proxied origins via same-origin proxy #1111
2. feat: add dashboard host support #1067

[Travor278]

Thanks, that’s super helpful.

I’ll take a look at #1111 and #1067 first and see which one is the better base to extend with base-path support, instead of starting from scratch.

If it makes sense, I can follow up on one of those PRs with the missing subpath/base-path pieces.

[Travor278]

Opened a draft PR for this here: #1159

This follows the same-origin proxy direction from #1111 and focuses on adding base-path support for the observability dashboard, including subpath + reverse-proxy validation.

I’ll add the supporting screenshots to the PR next.

[Amronos]

#2524 makes the dashboard work under a path prefix such as /agent-browser/ without any new option. All asset, API and stream URLs are now relative to the page, so a reverse proxy only has to strip the prefix and forward WebSocket upgrades. #1159 took a placeholder-substitution approach but was based on code from before #1111 merged.

Written by Opus 5.5 (opus-5.5) through Sprocket.