Claude Desktop (Code tab) overrides ANTHROPIC_BASE_URL: claude native lane never sees traffic, and auto-compact is left disabled

Summary

I'm asking for support for the Claude Desktop app's Code tab (CLAUDE_CODE_ENTRYPOINT=claude-desktop). bili plugin install claude installs cleanly, but the desktop host overrides ANTHROPIC_BASE_URL, so no model request reaches the proxy. The same managed block still applies DISABLE_AUTO_COMPACT=1. As a result, desktop sessions get no bili compression and no native auto-compaction.

Environment

billion-context 0.1.186 (npm global), Node v24.14.0
Windows 11 Pro
Claude Desktop 2.19675.1 (CLAUDE_CODE_DESKTOP_APP_VERSION), embedded Claude Code 2.1.288
Auth: claude.ai subscription OAuth via the desktop host (CLAUDE_CODE_SDK_HAS_HOST_AUTH_REFRESH=1)

Steps

npm install -g billion-context
bili plugin install claude. bili doctor then reports the claude lane as ok with env.ANTHROPIC_BASE_URL=http://127.0.0.1:18787/bili/https://api.anthropic.com.
Fully restart Claude Desktop and open a new Code-tab session.

Observed

The SessionStart hook runs: the proxy is live on 127.0.0.1:18787, /__bili/health is ok, and the bili MCP tools appear in the session.
The session's child environment shows ANTHROPIC_BASE_URL=https://api.anthropic.com. The desktop host sets this and overrides the value from ~/.claude/settings.json.
DISABLE_AUTO_COMPACT=1 from the same env block is applied.
/__bili/stats → "sessions": []. bili.log has no processTurn lines.
acp_status / acp_cache fail with unknown plugin conversation (no model request has arrived with this conversation id yet …), and the log shows [plugin] NO MODEL REQUESTS seen for conversation ….

Expected

Either compression works in Claude Desktop sessions, or the install and hook detect that the base URL is not being honored and leave auto-compaction enabled.

Suggestions

Guard: when CLAUDE_CODE_ENTRYPOINT=claude-desktop, or when the SessionStart hook sees the effective ANTHROPIC_BASE_URL differs from the managed one, warn loudly. Also avoid leaving the session with auto-compact disabled. bili doctor could flag this state too.
Desktop lane: find a seam that the desktop host doesn't override. A cert-MITM route (HTTPS_PROXY + NODE_EXTRA_CA_CERTS in the settings env block, as bili claude does for the CLI) might work, but I haven't tested it. It also means trusting the bili root CA for every desktop session, so I'd rather see an officially supported, documented path.

Workaround for now: bili claude (or the /bili/ base-URL prefix) from a terminal works for the CLI only.

@sonatique

[bot] 🏷 Triage: confirmed, reproducing by code inspection (no Claude Desktop in the agent sandbox — verified against the code paths your report implicates).

What's happening

bili plugin install claude writes the managed block into ~/.claude/settings.json: env.ANTHROPIC_BASE_URL (the /bili/ URL) + env.DISABLE_AUTO_COMPACT=1 + the SessionStart hook (applyClaudeManagedBlock in src/plugin-install.ts).
The desktop host spawns embedded Claude Code with its own ANTHROPIC_BASE_URL=https://api.anthropic.com (claude.ai host auth), which wins over settings.json for API routing — so no model request ever reaches the proxy (your /__bili/stats: [], no processTurn, unknown plugin conversation are all downstream of that one fact). Meanwhile DISABLE_AUTO_COMPACT=1 is honored — so the session loses both compression paths. Your observed state is fully explained.
Nothing detects it today: the hook exits silently, and bili doctor only audits install state (block present → ok).

What I'm implementing now (the guard half of your Expected)

SessionStart hook: detect that the managed URL isn't being honored — CLAUDE_CODE_ENTRYPOINT=claude-desktop (evidence-based match; I deliberately won't generalize to other entrypoints without traffic evidence) or the session env carrying ANTHROPIC_BASE_URL that isn't the bili URL — then warn loudly on stderr: both consequences (no bili compression; native auto-compact disabled by the managed block) plus remediation. The detection is also persisted to a small state file so doctor can surface it later.
bili doctor: the claude lane gets (a) a standing advisory when the Claude Desktop app is detected on disk (well-known Windows/macOS install locations only — absence never downgrades the verdict), and (b) the last hook-detected bypass with timestamp + reasons.

Why auto-compact can't be made conditional (your suggestion 1b): one static settings.json serves BOTH the CLI and the desktop hosts, and Claude Code has no host-conditional env seam. The hook cannot mutate its parent's environment mid-session, and moving DISABLE_AUTO_COMPACT ownership from the static block into the hook would break the first CLI session after install (DAC unset until the second session → double compression). So the deliverable is: loud warning + doctor flag + documented remediation, not a silent fix. If you are desktop-only: bili plugin remove claude restores your .bili-bak (native auto-compact returns); CLI sessions keep working through the managed block or bili claude.

The desktop lane (your suggestion 2) — needs owner sign-off + your field test before I build it. My recommendation: an opt-in path where the managed env block additionally carries HTTPS_PROXY + NODE_EXTRA_CA_CERTS (bili's root CA), routing only api.anthropic.com through the proxy (blind tunnel — everything else stays end-to-end TLS). Why plausible: the desktop demonstrably honors the settings env block (DAC proves it), Node honors those two vars, and the OAuth token rides transparently in the Authorization header. Why not yet: I cannot test it here, and baking CA trust into every desktop session is a trust decision — this repo's config-surface discipline says I don't ship untested trust extensions without explicit sign-off. @sonatique — if you want it, say so and I'll spec it as a separate opt-in for you to validate on your machine; otherwise the guard + docs land as-is.

中文结构化结论(七问)

是什么问题:Claude Desktop 的 Code 标签页以宿主自己的 ANTHROPIC_BASE_URL(claude.ai 主机鉴权)覆盖 settings.json 中 bili 管理的 URL,模型请求完全绕过代理;同一管理块的 DISABLE_AUTO_COMPACT=1 却仍生效——桌面会话既无 bili 压缩也无原生自动压缩。
什么原因导致:settings.json 是静态的、CLI 与桌面宿主共用一份,Claude Code 没有按宿主条件化 env 的接缝;桌面宿主在进程级注入自己的 base URL 且优先于 settings。检测侧此前零信号(hook 静默退出、doctor 只审安装态),陷阱因此无声。
怎么修复的(进行中):SessionStart hook 增加路由旁路检测(entrypoint=claude-desktop 或会话 env 的 ANTHROPIC_BASE_URL 非 bili URL)→ 响亮告警 + 落状态文件;bili doctor 对 claude lane 增加静态(磁盘上检测到桌面应用)与动态(上次 hook 检出记录)两类 warning。不做运行时改父进程 env(不可行),不把 DAC 所有权挪给 hook(会破坏 CLI 首会话)。
是否有回归问题:仅新增检测与告警;managed block 写入内容、hook 命令、repin 逻辑均不动;hook 维持「永不阻断 claude」契约(exit 0)。PR 提交后按七问复审逐项确认。
是否破坏缓存:不涉及压缩/缓存路径;新增一个内部状态文件(stateDir 下),不参与任何失效策略。
是否改了设计方向:无架构转向。桌面 MITM 通道为独立提案,待 owner 拍板,未实现。
是否引入新配置:无新 env/config 字段;状态文件为内部产物。README(en/zh)与 CLIENTS.md 将补桌面限制说明。

判定:guard 半边(检测+告警+doctor+文档)即将提 PR;桌面压缩半边(MITM)需 owner 批准 + 真机验证后再立项实现。

@sonatique

@sonatique 感谢详尽的复现。根因已在代码层确认,检测侧修复已进 PR #2291(CI 运行中);桌面路由方案等你/owner 拍板。

根因(代码验证):bili plugin install claude 往 ~/.claude/settings.json 写一个静态受管块(env.ANTHROPIC_BASE_URL + env.DISABLE_AUTO_COMPACT=1)。Claude Code 没有按 host 区分的 env 机制,桌面宿主启动内嵌 CC 时自带 ANTHROPIC_BASE_URL(覆盖 settings),而 DAC 仍从该块读取——于是桌面会话「既无 bili 压缩、也无原生自动压缩」,且全程静默。这一点无法靠安装期配置修掉:一份文件同时服务两个宿主,hook 也无法在会话中途改父进程 env。所以 #2291 交付的是检测 + 大声报警,不是静默改路。

#2291 做了什么:

SessionStart hook 在会话开始(代理拉起之前,拉不起来也照样报)做两个证据化检查:① CLAUDE_CODE_ENTRYPOINT 命中证据白名单(仅 claude-desktop,未来 host 需流量证据才加);② 会话环境里的 ANTHROPIC_BASE_URL 非空且不是受管 bili URL。命中任一 → stderr 醒目 WARNING(解释绕过原因、DAC 后果、修复路径),并把 {at, reasons} 记到 <XDG_STATE_HOME>/billion-context/claude-routing-warning.json(只写不抛)。
bili doctor 的 claude lane 新增两条 ⚠️ 提示(不影响 verdict):a) 本机检测到 Claude Desktop 安装(win32/darwin 路径,linux 不猜);b) hook 最近一次记录的绕过(带时间戳+原因)。
README 中英文的 claude 条目写明此限制与逃生路径。
行为变更披露(纯增量):此前该状态完全静默 → 现在每次此类会话开始有 stderr 警告( claude --debug 可见)+ doctor ⚠️ 行;未改任何既有输出格式、wire、config;零新配置/env/CLI flag(marker 是内部状态)。
终端会话不受影响:健康 CLI 会话两个信号都不命中(注意:若你 shell 里自己 export 了别的 relay URL,信号②也会提示——那种情况忽略或 unset 即可,我们宁可误报不漏报)。

你的即时 workaround:CLI 继续用 bili claude;如果只用桌面端,bili plugin remove claude 恢复 .bili-bak(原生自动压缩回来)。

后半段(让桌面真正能压缩)——待决策:我的建议是 opt-in cert-MITM 路线:在受管 env 块里加 HTTPS_PROXY + NODE_EXTRA_CA_CERTS 两键(bili 自签 CA + 代理 HTTP 端口)。依据:桌面宿主确实会读 settings env 块(DAC 就是证据)、Node 认这两个变量、OAuth token 走 Authorization 头可透明过隧道、非白名单主机保持端到端加密。但:① 这等于往你的 settings.json env 块写新键,按仓库规矩需要 owner 先 sign-off;② 本沙盒无法实测,需要在真机 Claude Desktop 上验证(你有环境)。如果你认可方向,请在本线程确认两点:默认关还是默认开,以及是否接受桌面会话信任 bili CA;我随后单独开 follow-up PR 实现。

七问:

是什么问题:桌面宿主覆盖受管 ANTHROPIC_BASE_URL,桌面会话同时失去两种压缩,且完全静默。
什么原因导致的:单一静态 settings.json 服务 CLI+桌面两个宿主;Claude Code 无按 host 分支机制;hook 无法修改父进程 env。
怎么修复的:证据化双信号检测(entrypoint 白名单 + URL 失配)→ hook 大声警告 + 持久 marker + doctor 双通道提示 + 文档;不改任何语义。
是否有回归问题:无。纯增量的警告/marker;健康 CLI 路径两信号均不命中(有单测钉住);verdict、wire、config 不受影响。
是否破坏缓存:不涉及(无缓存/重试/游标语义;marker 为单值 latest-wins 记录)。
是否改了设计方向:没有。检测侧复用既有 state-dir + doctor advisory 机制;MITM 路线属新 lane 提案,待批准后才动。
是否引入了新的配置:零(无新 config/env/CLI flag;marker 文件为内部状态)。

结论:检测侧完成,#2291 CI 绿即可合;桌面路由侧阻塞于 owner/用户决策,issue 保持打开跟踪后半段。

补充:#2291 的 CI 已全部通过(21/21 checks green,含 ubuntu/windows 双平台全量测试、e2e lane 套件、docs-sync/coverage、kernel-guard)。PR 状态:可合并——按仓库规矩由人工合并,链接同前:#2291。桌面路由(MITM opt-in)方案仍等本线程拍板。

@ranxianglei

@ranxianglei : I want the special opt-in for me to validate on my machine

收到——但在动手写 opt-in 之前,先给你看一个仓库里已有的关键证据,然后是一个 5 分钟、完全可逆的验证步骤。这个步骤的结果决定 opt-in 该不该建、怎么建。

为什么我先不直接提交 opt-in 代码:本仓库两周前(PR #1586)就有实测结论——Claude Code 的 undici fetch 忽略 HTTPS_PROXY(见 src/launcher.ts:412-416)。这正是 bili claude 启动器对 claude 用 /bili/ base-URL 改写而不是 cert-MITM 的原因。也就是说「往 settings env 块写 HTTPS_PROXY + NODE_EXTRA_CA_CERTS」这条路在 CLI 上已被证伪过。但桌面内嵌的是特定新版 CC(2.1.288),且桌面宿主的 env 注入方式可能不同——行为是否改变只有你的真机能回答。在核心机制存疑时先把 200 行安装器/hook/文档代码投机构建出来,不符合这个仓库的纪律;先拿决定性证据,证据到位我立刻建。

验证步骤(只改你自己 settings.json 的一两行,测完删掉即可):

终端起一个固定端口的代理实例(所有 bili 代理实例 MITM 默认开启,且 api.anthropic.com 在默认 MITM 白名单里):
bili start --port 18999
测试期间保持它存活。
编辑 ~/.claude/settings.json 的 env 块,加一行:
"HTTPS_PROXY": "http://127.0.0.1:18999"
完全重启 Claude Desktop,开新 Code 会话,发一条消息。
看这个实例的 bili.log,按结果对号入座:
- 出现 mitm api.anthropic.com:443 ... REJECTED the MITM certificate ... CA: <路径> → 路由成功(HTTPS_PROXY 被尊重了!),只差证书信任 → 做第 5 步
- 出现任何 CONNECT / tunnel api.anthropic.com:443 established / mitm api.anthropic.com 行 → 路由成功
- 会话报 TLS/cert 类错误 → 同属「路由成功」档
- 会话正常但日志完全没有上述行 → CC 依然忽略 HTTPS_PROXY → 此路不通,我会把「桌面端无可用路由缝隙」作为已知限制写进文档收尾
若是证书拒绝:把日志里打印的那个 CA 路径填进 env 块 "NODE_EXTRA_CA_CERTS": "<路径>",重启 Desktop 重试。若随后出现 processTurn 行、/__bili/stats 有 sessions → 全链路打通,我立刻把正式 opt-in 作为 fix(claude): detect Claude Desktop base-URL override at session start (#2290) #2291 的后续 commit 交付(installer 开关 + hook 每会话重钉端口 + doctor 状态位 + en/zh 文档 + CONFIGURATION.md)。
清理:删掉加的行,停掉 bili start 实例。

请顺手回传三项(公开线程,务必脱敏):① 第 4 步落在哪一档;② 相关 bili.log 行(host 被掩码没关系);③ 内嵌会话 env 里这些变量的名字(URL/路径类的值可以贴):切勿贴任何 token/key/凭据 —— ANTHROPIC_BASE_URL、HTTP_PROXY/HTTPS_PROXY/ALL_PROXY/NO_PROXY、NODE_EXTRA_CA_CERTS、CLAUDE_CODE_ENTRYPOINT、DISABLE_AUTO_COMPACT、CLAUDE_CODE_DESKTOP_APP_VERSION。第③项能区分两种死法:「桌面宿主自己设了代理变量、覆盖了我们的值」vs「CC 压根不读这些变量」——两者对应的后续动作完全不同。

@ranxianglei

@ranxianglei Thank you, but please reply with instructions in English

Noted — English it is, from now on in this thread. Here is the full instruction set:

First, one important finding, then a 5-minute, fully reversible probe. Its outcome decides whether and how the opt-in gets built.

Why I am not shipping opt-in code yet: this repo has a measured conclusion from two weeks ago (PR #1586) — Claude Code's undici fetch ignores HTTPS_PROXY (see src/launcher.ts:412-416). That is exactly why the bili claude launcher routes claude via the /bili/ base-URL rewrite instead of cert-MITM. So "write HTTPS_PROXY + NODE_EXTRA_CA_CERTS into the settings env block" has already been disproven for the CLI. The desktop embeds a specific newer CC (2.1.288) whose env-injection path may differ — only your machine can answer that. Building ~200 lines of installer/hook/docs code on top of an unproven core mechanism goes against this repo's discipline; get the decisive evidence first, and I build immediately once it lands.

Validation steps (only touches your own settings.json by one or two lines; remove them afterwards):

Start a fixed-port proxy instance in a terminal (every bili proxy instance has MITM enabled by default, and api.anthropic.com is in the default MITM whitelist):
bili start --port 18999
Keep it alive for the whole test.
Edit the env block in ~/.claude/settings.json and add one line:
"HTTPS_PROXY": "http://127.0.0.1:18999"
Fully restart Claude Desktop, open a new Code-tab session, send one message.
Watch that instance's bili.log and match the result:
- mitm api.anthropic.com:443 ... REJECTED the MITM certificate ... CA: <path> → routing works (HTTPS_PROXY was honored!); only cert trust is missing → go to step 5
- any CONNECT / tunnel api.anthropic.com:443 established / mitm api.anthropic.com line → routing works
- the session fails with a TLS/cert-style error → also counts as "routing works"
- the session works normally but none of the above lines appear → CC still ignores HTTPS_PROXY → this route is dead; I will then document "no usable routing seam on desktop" as a known limitation and wrap up
If you hit the cert rejection: take the exact CA path printed in that log line and add it to the env block as "NODE_EXTRA_CA_CERTS": "<path>", restart Desktop, retry. If processTurn lines then appear and /__bili/stats shows sessions → full chain proven, and I will ship the proper opt-in right away as follow-up commits on fix(claude): detect Claude Desktop base-URL override at session start (#2290) #2291 (installer flag + hook per-session port re-pin + doctor status + en/zh docs + CONFIGURATION.md).
Cleanup: delete the added line(s) and stop the bili start instance.

Please report back three things (public thread — sanitize carefully): ① which bucket step 4 landed in; ② the relevant bili.log lines (masked hosts are fine); ③ the names of these variables in the embedded session's env (URL/path values OK to include) — never paste any token/key/credential: ANTHROPIC_BASE_URL, HTTP_PROXY/HTTPS_PROXY/ALL_PROXY/NO_PROXY, NODE_EXTRA_CA_CERTS, CLAUDE_CODE_ENTRYPOINT, DISABLE_AUTO_COMPACT, CLAUDE_CODE_DESKTOP_APP_VERSION. Item ③ distinguishes two different failure modes — "the desktop host sets its own proxy vars and overrides ours" vs "CC never reads these vars at all" — and the follow-up action differs for each.

@ranxianglei

@ranxianglei where is bili.log ?

On your machine (Windows 11, default locations) it is:

C:\Users\<your-user>\.local\state\billion-context\bili.log

Notes:

bili uses XDG-style paths on every platform: $XDG_STATE_HOME/billion-context/bili.log, falling back to ~/.local/state/billion-context/bili.log (~ = your profile dir on Windows). A custom location is only used if you set XDG_STATE_HOME or ACP_LOG_FILE / "logFile" in billion-context.json — you haven't, so the path above applies.
All proxy instances on the machine share that one log file, so while testing, look for lines from your --port 18999 instance (its startup line shows the port; the mitm/tunnel lines appear when desktop traffic hits it).
Quick check that you're looking at the right file: right after starting bili start --port 18999, the file gets a fresh startup line; or run bili doctor, which reports the state dir it uses.

While you're there, the grep targets for step 4: CONNECT, tunnel api.anthropic.com, mitm api.anthropic.com, REJECTED the MITM certificate, and later processTurn.

@ranxianglei

@ranxianglei : I did exactly what you asked. Here is the exact output:
PS C:\Users\me> bili start --port 18999
2026-10-06T21:24:39.278Z [info] [v=0.1.186] [persist] enabled
2026-10-06T21:24:39.280Z [info] [v=0.1.186] [log] writing to C:\Users<my-user>.local\state\billion-context\bili.log
2026-10-06T21:24:39.281Z [info] [v=0.1.186] [conn] keepAliveTimeout=5000ms clientErrorBackstop=30000ms
2026-10-06T21:24:39.291Z [info] [v=0.1.186] [update] auto-update enabled (checking every 180s)
2026-10-06T21:24:39.291Z [info] [v=0.1.186] [advisory] watcher enabled (checking every 180s, independent of auto-update)
2026-10-06T21:24:39.291Z [info] [v=0.1.186] [release-notes] watcher enabled (checking every 180s, visibility only — never installs)
2026-10-06T21:24:39.314Z [info] [v=0.1.186] acp-proxy v0.1.186 listening on http://127.0.0.1:18999 — web UI: http://127.0.0.1:18999/__bili/ — zero-config: prefix any baseURL with http://127.0.0.1:18999/bili/ — MITM proxy on (whitelist)
2026-10-06T21:24:49.305Z [info] [v=0.1.186] [update] checking npm registry for billion-context (last check 138s ago)…
2026-10-06T21:24:49.540Z [info] [v=0.1.186] [update] current=0.1.186 latest=0.1.186 tag=latest (up to date)

Step 1 confirmed healthy — that last line is exactly what we need: acp-proxy v0.1.186 listening on http://127.0.0.1:18999 … MITM proxy on (whitelist). The instance is up with MITM termination armed for api.anthropic.com.

But that output only covers ~10 seconds of the instance's life — it tells me nothing yet about whether desktop traffic arrived. Two questions:

Did you complete steps 2–3? (add the "HTTPS_PROXY": "http://127.0.0.1:18999" line to the env block in ~/.claude/settings.json, fully quit Claude Desktop — including the tray icon, closing the window is not enough — relaunch, open a NEW Code-tab session, send one message.)

If not yet — go ahead and do that now, then paste whatever new lines appear in the terminal/log after you send the message.
If yes, and the log stayed exactly as quiet as your paste — that's a negative signal (no CONNECT reached the proxy). Before we call the route dead, run one 2-minute control test that removes every doubt:
1. Change the value to a dead port: "HTTPS_PROXY": "http://127.0.0.1:18998" (nothing listens there).
2. Fully restart Claude Desktop, new session, send one message.
3. Interpret:
  - the message fails (connection-refused / proxy error / hang) → the variable IS honored by the host — which makes the silent 18999 run puzzling and worth digging into (send me the session's error text);
  - the message works normally → the embedded CC genuinely ignores HTTPS_PROXY, same as the CLI finding in PR fix: native omp identity stamp + tool registration mirror the fetch interceptor (#1579) #1586 → the MITM route is dead on desktop too; I will then document "no usable routing seam on Claude Desktop" as a known limitation (README en/zh + issue close-out), keeping the detection guard from fix(claude): detect Claude Desktop base-URL override at session start (#2290) #2291 as the shipped mitigation.

Either way, when you're done please include the three items from before: which bucket you landed in, the relevant log lines, and the names of ANTHROPIC_BASE_URL, any *PROXY* vars, NODE_EXTRA_CA_CERTS, CLAUDE_CODE_ENTRYPOINT, DISABLE_AUTO_COMPACT, CLAUDE_CODE_DESKTOP_APP_VERSION in the embedded session's env (URL/path values OK — never tokens/keys/credentials).

@ranxianglei

@ranxianglei : I did complete all steps, but maybe I made the "add HTTPS_PROXY ... line to the env block .." wrong. I didn't use the env block (I don't know what it is). My complete settings.json after I edited is:
"
{
"agentPushNotifEnabled": true,
"inputNeededNotifEnabled": true,
"HTTPS_PROXY": "http://127.0.0.1:18999"
}
"
so: there is no env block. Advise what settings.json shall looks like

@ranxianglei

@ranxianglei : Ok, I found how to use the env block. My settings.json is now exactly:
{
"agentPushNotifEnabled": true,
"inputNeededNotifEnabled": true,
"env": {
"HTTPS_PROXY": "http://127.0.0.1:18999"
}
}

I executed all steps exactly as requeted. The log is as follow:

PS C:\Users\me> bili start --port 18999
2026-10-06T21:45:52.938Z [info] [v=0.1.186] [persist] enabled
2026-10-06T21:45:52.940Z [info] [v=0.1.186] [log] writing to C:\Users\me.local\state\billion-context\bili.log
2026-10-06T21:45:52.943Z [info] [v=0.1.186] [conn] keepAliveTimeout=5000ms clientErrorBackstop=30000ms
2026-10-06T21:45:52.954Z [info] [v=0.1.186] [update] auto-update enabled (checking every 180s)
2026-10-06T21:45:52.955Z [info] [v=0.1.186] [advisory] watcher enabled (checking every 180s, independent of auto-update)
2026-10-06T21:45:52.955Z [info] [v=0.1.186] [release-notes] watcher enabled (checking every 180s, visibility only — never installs)
2026-10-06T21:45:52.979Z [info] [v=0.1.186] acp-proxy v0.1.186 listening on http://127.0.0.1:18999 — web UI: http://127.0.0.1:18999/__bili/ — zero-config: prefix any baseURL with http://127.0.0.1:18999/bili/ — MITM proxy on (whitelist)
2026-10-06T21:46:02.983Z [info] [v=0.1.186] [update] checking npm registry for billion-context (last check 743s ago)…
2026-10-06T21:46:03.282Z [info] [v=0.1.186] [update] current=0.1.186 latest=0.1.186 tag=latest (up to date)

go on

docs(claude): record #2290 field-test verdict - HTTPS_PROXY route dea…

@Dog

@Dog @sonatique — wrapping up per "go on". Probe verdict: negative. The MITM route does not work on Claude Desktop, so the opt-in will not be built.

Evidence (your floor-20 run): the setup was exactly right — live proxy at 127.0.0.1:18999 with MITM proxy on (whitelist) covering api.anthropic.com, HTTPS_PROXY correctly inside the env block, full desktop restart. And yet the instance log shows zero activity from the desktop session: no CONNECT, no tunnel, no mitm, no processTurn. The decisive model-API path never produced a single CONNECT — the variable did not route model traffic. This matches the repo's existing CLI finding that Claude Code's undici fetch ignores proxy env vars (src/launcher.ts:412-416, PR #1586), which is exactly why bili claude uses the /bili/ base-URL rewrite instead of cert-MITM. One honesty caveat: if your message actually failed with a TLS/proxy error rather than working normally (direct to Anthropic), tell me — that would change the reading.

Conclusions & actions:

As of Claude Desktop 2.19675.1 / embedded CC 2.1.288 there is no usable routing seam on the Code tab: ANTHROPIC_BASE_URL is overridden by the host, and HTTPS_PROXY does not reach the model path. Shipping an opt-in whose core mechanism just failed on real hardware would violate this repo's discipline — documented instead.
Field-test verdict recorded in README en/zh as a known limitation — commit 3cc7e9f42 on PR #2291; the PR body now carries the verdict too, and CI re-ran on the docs commit.
Your machine state: your current settings.json no longer contains the bili managed block (you evidently removed the native install) — so your desktop sessions have native auto-compaction back; what remains missing is compression only, which we've now proven unroutable on that version. CLI keeps working via bili claude or the /bili/ prefix.
If Anthropic changes behavior upstream (stops overriding the base URL, honors proxy vars, or adds a proxy setting), this lane can be revisited — Claude Desktop (Code tab) overrides ANTHROPIC_BASE_URL: claude native lane never sees traffic, and auto-compact is left disabled #2290 stays open to track that, and the detection guard from fix(claude): detect Claude Desktop base-URL override at session start (#2290) #2291 is the shipped mitigation in the meantime.

中文结构化结论(七问)

是什么问题:桌面宿主覆盖受管 ANTHROPIC_BASE_URL,桌面会话既无 bili 压缩也无原生自动压缩;后半段要验证 cert-MITM 路线是否可行。
什么原因导致:单一静态 settings.json 双宿主共用、无按 host 分支机制(检测侧根因);MITM 路线失败的原因:内嵌 CC 的模型请求路径不读 HTTPS_PROXY(与 CLI 侧 fix: native omp identity stamp + tool registration mirror the fetch interceptor (#1579) #1586 既有结论一致)。
怎么修复的:检测侧(evidence-permitlist 双信号 hook 告警 + doctor 提示,fix(claude): detect Claude Desktop base-URL override at session start (#2290) #2291)已交付;路由侧经真机证伪后不建,改为把验证结论写入文档。
是否有回归问题:无。本轮仅改 README en/zh 两个 bullet;代码零改动。
是否破坏缓存:不涉及。
是否改了设计方向:无转向——「证据不足不建投机特性」纪律的执行;lane 保持跟踪待上游变化。
是否引入新的配置:零。

判定:issue 的两条 Expected 路径均已走到终点——检测侧完成(#2291,等人工合并),压缩侧经真机验证不可行并已文档化。#2291 可合并;#2290 建议在其合并后由 owner/作者关闭(或保留跟踪上游变化,均可)。

Final status update: CI on the last commit (3cc7e9f42, docs verdict) is 21/21 green. Summary of where #2290 stands:

Detection half — done: SessionStart hook routing-bypass warning + durable marker + bili doctor advisories + README en/zh limitation notes, all in PR #2291 (ready for human merge).
Compression half — field-proven infeasible and documented: real-machine probe on Claude Desktop 2.19675.1 / embedded CC 2.1.288 showed zero CONNECT traffic through HTTPS_PROXY, consistent with the CLI finding that CC ignores proxy env vars (fix: native omp identity stamp + tool registration mirror the fetch interceptor (#1579) #1586); verdict recorded in README en/zh and the PR body. No opt-in will be shipped on a disproven mechanism.
Issue stays open solely to track upstream behavior changes; once fix(claude): detect Claude Desktop base-URL override at session start (#2290) #2291 merges, owner/author may close it or keep it as the upstream-watch tracker.

Nothing further pending from my side.

@ranxianglei

@ranxianglei maybe something that wasn't clear to me when I did the experiment and consequently I may have done it wrong : when I followed the steps, bili was NOT installed.
Reading your last comments I now understand that I should have run the experiment with bili installed. Is this correct? If yes I can install bili and then re-run the experiment. Just tell me, I'll be happy to help.

Good question — let me clear up a terminology mix-up first, then answer directly.

What was and wasn't installed: the bili binary itself was installed — your log shows it running (acp-proxy v0.1.186 listening on http://127.0.0.1:18999 … MITM proxy on (whitelist)). What was absent is the claude native lane: the managed block in ~/.claude/settings.json (ANTHROPIC_BASE_URL / DISABLE_AUTO_COMPACT=1 / the SessionStart hook). Your floor-20 settings.json confirms it — only your two notification flags plus the env block you added. You evidently removed the native install at some point (it was the workaround I suggested).

Direct answer: no — the experiment does not need the native lane installed, and the verdict stands. The probe measures one thing: does the desktop's embedded Claude Code route model traffic through a HTTPS_PROXY taken from the settings env block? The managed block is irrelevant to that question, for three reasons:

Your standalone bili start --port 18999 instance was already fully capable — MITM termination armed for api.anthropic.com (that startup line says so). Nothing about the native lane is needed for the proxy side to receive and decrypt traffic.
Even with the lane installed, the desktop overrides ANTHROPIC_BASE_URL anyway (that's the original bug) — so model traffic would still target https://api.anthropic.com, and the only open question remains "does HTTPS_PROXY steer it to us?" The managed block changes nothing about that.
If the desktop host filters which env keys it forwards, it does so by key name — adding the managed block's other keys would not cause it to suddenly forward HTTPS_PROXY. The zero-CONNECT result holds either way.

Optional: one 2-minute test that closes the last interpretive gap. We can distinguish "the variable is delivered but ignored by CC" from "the host never delivers it". Run it exactly as before, but pointing at a dead port:

In the env block set "HTTPS_PROXY": "http://127.0.0.1:18998" (nothing listens there; no bili start needed).
Fully restart Claude Desktop (tray icon included), new Code session, send one message.
Read: the message fails (connection-refused / proxy error / hang) → the variable is delivered and honored, which makes the silent 18999 run a genuine puzzle worth digging into — send me the exact error text. The message works normally → the variable provably never reaches the model path; the "no usable routing seam" conclusion becomes airtight and I will finalize the docs wording accordingly.

This test works with or without the native lane. One practical caveat if you do want to reinstall the lane for the test: on the currently released 0.1.186 that would re-arm the DISABLE_AUTO_COMPACT=1 trap for your desktop sessions (the fix only lands when #2291 is merged) — so remove it again afterwards, or skip the reinstall entirely.

Merge pull request #2291 from ranxianglei/2026-10-07_claude-desktop-r…

fix(claude): detect Claude Desktop base-URL override at session start (…

Navigation Menu

Repository navigation

Claude Desktop (Code tab) overrides ANTHROPIC_BASE_URL: claude native lane never sees traffic, and auto-compact is left disabled #2290

Summary

Environment

Steps

Observed

Expected

Suggestions

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Claude Desktop (Code tab) overrides ANTHROPIC_BASE_URL: claude native lane never sees traffic, and auto-compact is left disabled #2290

Description

Summary

Environment

Steps

Observed

Expected

Suggestions

Activity

ranxianglei commented on Oct 6, 2026

ranxianglei commented on Oct 6, 2026

ranxianglei commented on Oct 6, 2026

sonatique commented on Oct 6, 2026

ranxianglei commented on Oct 6, 2026

sonatique commented on Oct 6, 2026

ranxianglei commented on Oct 6, 2026

sonatique commented on Oct 6, 2026

ranxianglei commented on Oct 6, 2026

sonatique commented on Oct 6, 2026

ranxianglei commented on Oct 6, 2026

sonatique commented on Oct 6, 2026

sonatique commented on Oct 6, 2026

ranxianglei commented on Oct 6, 2026

ranxianglei commented on Oct 7, 2026

ranxianglei commented on Oct 7, 2026

sonatique commented on Oct 7, 2026

ranxianglei commented on Oct 7, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions