Sub-path (basePath) deployment — reviving #370 with the full implementation you asked for

[c-with]

Hi — I'd like to gauge interest before putting in the work.

Context: I run pi-web behind a reverse proxy at a sub-path (https://my-domain/pi/), which is a deployment shape the current build doesn't support (all client URLs are root-absolute). In practice this bites in several places: Next.js RSC navigation returns 307 Location: /?_rsc (yanking the browser to the site root), API calls resolve against the origin root, and the service worker assumes root scope.

I'm aware of #370 by @windli2018 and your review there. The feedback was clear and actionable — the concept was fine, the execution incomplete:

1. Several client-generated URLs still bypassed apiUrl() / withBasePath() (session context loading, deferred thinking content, full Bash output, file upload/download, local Markdown images, session export, offline-page icon)
2. public/sw.js treated self.registration.scope as a pathname when it is a full URL, breaking cache matching for both root and prefixed deployments
3. Two unrelated features bundled in one PR
4. Needed rebase against main (conflicts in components/MessageView.tsx, hooks/useAgentSession.ts)

What I'm proposing to submit, exactly per that review:

• One focused PR: PI_WEB_BASE_PATH support with every client-generated internal URL routed through withBasePath()/apiUrl(), plus the sw.js scope fix
• Regression tests covering both root and prefixed deployments — I have a live prefixed deployment to verify against (307-to-root repro before, clean navigation after)
• Rebased on current main
• The oversized-message guard left out entirely (separate concern, happy to see it land on its own merits)

Two questions before I start:

1. Is this still a contribution you'd consider merging, or has your thinking on sub-path support changed since feat: sub-path (basePath) deployment support + oversized message guard #370?
2. If yes — any additional requirements beyond the list above? (e.g. env var naming, whether PI_WEB_BUILD_BASEPATH=1 build-time baking is still the mechanism you prefer for production builds)

Thanks for the project; the session/workspace model has been great to work with.

---

背景说明（中文）：

我在反代子路径（https://我的域名/pi/）下运行 pi-web，当前构建不支持这种部署形态——客户端所有 URL 都是根绝对路径。实际踩到的坑包括：Next.js RSC 导航返回 307 Location: /?rsc（把浏览器拽回站点根路径）、API 请求解析到源站根、service worker 假设根 scope。

我知道 #370 和你的 review。按那份清单我准备完整重做：单一聚焦 PR、全部客户端 URL 走 withBasePath()/apiUrl()、修 sw.js scope、root 和 prefixed 两套回归测试（我有一个线上 prefixed 部署可以验证：修复前 307 到根，修复后导航正常）、基于最新 main rebase、不含超大消息守卫。

两个问题：1) 这个方向你还愿意收吗？2) 若愿意，清单之外还有别的要求吗（环境变量命名、生产构建是否仍用 PI_WEB_BUILD_BASEPATH=1 烘焙机制）？

感谢这个项目，session/workspace 模型用起来很顺手。

[agegr]

Thanks for checking in. We've decided not to support sub-path deployments for now, since supporting Next.js basePath end to end would add build-time and ongoing maintenance complexity. Please use a dedicated host or subdomain and serve Pi Web at the origin root.