[BUG] OpenCode plugin never sends x-headroom-project — Per-Project Savings dashboard can't attribute OpenCode traffic

[artsaraiva]

Summary

The OpenCode transport plugin (headroom/providers/opencode/_dist/entry.opencode.js) sets HEADROOM_PROJECT as a spawned-subprocess env var only (shell.env hook, derived from input.project.id), but the fetch/http/https wrapping installed by installHeadroomTransport only ever sets x-headroom-base-url / x-headroom-original-path headers on routed requests. It never sets x-headroom-project.

Server-side, headroom/proxy/project_policy.py (classify_project) only attributes savings via the x-headroom-project header or a /p/<name> URL-path prefix. Since the OpenCode plugin never sends either on the actual proxied HTTP requests, every OpenCode request routed through Headroom is unattributed — the dashboard's "Per-Project Savings" panel permanently shows 0 project(s) for OpenCode users, even with --memory --memory-storage project running correctly (that's a separate, cwd-based attribution path used only for the memory DB, not for cost/savings attribution).

Environment

• headroom-ai 0.34.0
• OpenCode (current, plugin loaded via packaged _dist/entry.opencode.js)
• macOS arm64

Reproduction

1. Run headroom proxy --memory --memory-storage project (or any profile with the OpenCode plugin active).
2. Use OpenCode with the Headroom transport plugin loaded (OPENCODE_CONFIG_CONTENT → plugin: [...entry.opencode.js]).
3. Make several requests through the proxy.
4. Open the Headroom dashboard → "Per-Project Savings" panel stays at 0 project(s) / "No per-project data yet." regardless of traffic volume.

Expected

OpenCode traffic routed through the proxy should be attributable per-project, same as Claude Code (/p/<name> base URL) or any client sending x-headroom-project.

Suggested fix

Resolve input.project.id (falling back to pluginOptions.project / input.directory) once at plugin init in HeadroomPlugin, thread it through installHeadroomTransport's state, and set an x-headroom-project header alongside the existing x-headroom-base-url header in both header-construction seams:

• mergeFetchHeaders (used by the wrapped fetch)
• headersForNodeRequest (used by the wrapped http.request/https.request)

I have a working patch against the packaged _dist/entry.opencode.js (adds a project parameter threaded through installHeadroomTransport → wrapRequest/routedNodeOptions → headersForNodeRequest, and through the fetch wrapper → withRoutedFetchInput → mergeFetchHeaders) and can share a diff/PR if useful.

Related but distinct issues

• [BUG] headroom wrap codex returns 403 for WebSocket transport when using /p/<project> routing #2355 — /p/<project> WebSocket 403 for headroom wrap codex (a routing bug on an already-attributed path, not this gap)
• [BUG] packaged OpenCode plugin references missing hook shim #2678 — packaged OpenCode plugin references a missing hook-shim/handler.js file (separate bundling bug, unrelated to project attribution)

[artsaraiva]

Follow-up: the first fix used input.project.id, which is OpenCode's internal opaque project hash (e.g. f8afc921e5b02427ced478177efd5a70dd9023e7) — it shows up correctly in the Per-Project Savings table, but as an unreadable hash instead of a project name.

Better resolution order: prefer the basename of input.directory (human-readable, e.g. my-project) and only fall back to input.project.id if no directory is available. Updated the local patch accordingly:

const directoryName = input.directory ? nodeRequire("node:path").basename(input.directory) : void 0;
const project = pluginOptions.project ?? directoryName ?? input.project?.id;

Verified locally: with directory: "/path/to/my-project", HEADROOM_PROJECT now resolves to my-project instead of the hash, and the dashboard's Per-Project Savings row now attributes to the same readable name that Claude Code's /p/<project-name> convention already uses.

[gingeekrishna]

PR open: #2868

Root cause: installHeadroomTransport was called with only { proxyUrl, debug }. The project value (resolved from pluginOptions.project → input.project.id → input.directory) was set as a shell env var in the shell.env hook for child processes, but neither mergeFetchHeaders (wrapped fetch) nor headersForNodeRequest (wrapped http.request/https.request) knew about it. Every proxied HTTP request went out without x-headroom-project.

Fix: Thread project through InstallOptions → TransportState → both header-building seams. The project value is resolved once at plugin init and passed to installHeadroomTransport. The shell.env hook reuses the same resolved value.

3 new tests in transport.test.ts: project header on fetch, project header on https.request, no header when project unset. All 17 tests pass. _dist/entry.opencode.js rebuilt with npm run build:standalone.