Git branch display in footer becomes stale after branch switch

[qwen-code-dev-bot]

Important

Thanks for taking the time to fill out this bug report!

Please search existing issues to see if an issue already exists for the bug you encountered.

What happened?

The git branch name displayed in the footer (below the input prompt) does not update when the user switches branches externally (e.g. git checkout branch2 or git switch branch2). Running /clear also does not refresh it. The stale branch name persists until the next fs.watch event fires (which may never happen on some filesystems).

What did you expect to happen?

The branch name in the footer should update within a few seconds of switching branches, regardless of the filesystem type.

Steps to reproduce

1. Start qwen-code in a git repo on branch feature-1
2. Confirm the footer shows feature-1
3. In another terminal (or via !git switch feature-2), switch to feature-2
4. Observe the footer still shows feature-1
5. Run /clear — footer still shows feature-1

Root cause

useGitBranchName (packages/cli/src/ui/hooks/useGitBranchName.ts) uses watchRepoBranch which sets up fs.watch on .git/logs/HEAD (the reflog). Two problems:

1. fs.watch is unreliable on some filesystems (NFS, FUSE, Docker overlay, some Linux filesystems). Events can be silently dropped, leaving the branch name stale with no recovery path.

2. No polling fallback. Unlike the extension file watcher which has both fs.watch and a generation-based polling fallback, the branch watcher has no polling. If the watch event is missed, the branch name stays stale indefinitely.

3. /clear does not trigger a refresh. The useEffect in useGitBranchName depends on [cwd]. Since /clear doesn't change cwd, the effect doesn't re-run and no refresh occurs.

Suggested fix

1. Add a polling fallback (e.g. every 5-10 seconds) in watchRepoBranch or useGitBranchName that calls resolveBranchName and compares with the current value, triggering onChange if different.

2. Alternatively, expose a refreshGitBranch() function and call it from /clear, new message submission, and other session lifecycle events.

Environment

• Qwen Code: v0.20.1 / v0.21.0
• OS: Linux (reported on multiple filesystem types)

Anything else we need to know?

resolveBranchName itself does NOT cache — it reads .git/HEAD directly every call. The problem is purely that the watcher doesn't fire and there's no fallback to trigger a re-read.

[qwen-code-ci-bot]

✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

[qwen-code-ci-bot]

Triage

• Type: bug
• Labels: type/bug, category/ui, scope/git, priority/P3
• Next: confirmed root cause — polling fallback needed in watchRepoBranch

Root cause confirmed via static analysis of packages/core/src/utils/gitDirect.ts and packages/cli/src/ui/hooks/useGitBranchName.ts:

• watchRepoBranch (gitDirect.ts:282) sets up fs.watch on <gitDir>/logs/HEAD with no polling fallback. When the watcher's 'error' event fires (e.g. reflog removed by git gc, inode change, platform watch limit), the watcher is closed, the map entry is deleted, and subscribers silently stop receiving updates — the code comment explicitly says "subscribers simply stop auto-refreshing."
• useGitBranchName depends on [cwd] for its useEffect, so /clear (which doesn't change cwd) never triggers a re-read.
• resolveBranchName itself is stateless (reads .git/HEAD directly each call), so a periodic poll would be trivial to add.
• The same pattern affects packages/cli/src/serve/workspace-git-state.ts (web shell server side).

Fix direction: add a polling interval (e.g. 5–10s) in useGitBranchName that calls resolveBranchName and compares with current state, or add a generation-based polling fallback in watchRepoBranch similar to the extension file watcher. The latter would also fix the web shell consumer.

Not verified: live reproduction was not executed (unattended CI run — static analysis only).

中文说明

• 类型: bug
• 标签: type/bug, category/ui, scope/git, priority/P3
• 下一步: 已确认根因——watchRepoBranch 需要轮询兜底

根因已确认（静态分析 packages/core/src/utils/gitDirect.ts 和 packages/cli/src/ui/hooks/useGitBranchName.ts）：

• watchRepoBranch（gitDirect.ts:282）对 <gitDir>/logs/HEAD 使用 fs.watch，无轮询兜底。当 watcher 触发 'error' 事件（如 reflog 被 git gc 删除、inode 变更、平台 watch 上限），watcher 被关闭、map 条目被删除，订阅者静默停止更新——代码注释明确写着 "subscribers simply stop auto-refreshing"。
• useGitBranchName 的 useEffect 依赖 [cwd]，/clear 不改变 cwd，因此不会触发重新读取。
• resolveBranchName 本身无状态（每次直接读 .git/HEAD），添加定时轮询非常简单。
• 同样的模式也影响 packages/cli/src/serve/workspace-git-state.ts（Web Shell 服务端）。

修复方向: 在 useGitBranchName 中添加轮询间隔（如 5-10 秒），调用 resolveBranchName 并与当前值比较；或在 watchRepoBranch 中添加类似扩展文件 watcher 的基于 generation 的轮询兜底（后者同时修复 Web Shell 消费端）。

未验证: 未执行实际复现（无人值守 CI 运行——仅静态分析）。

— Qwen Code · qwen3.8-max-preview

[doudouOUC]

Thanks for the detailed report and root cause analysis — I can confirm it's accurate after reviewing the code.

Confirmed root cause:

watchRepoBranch in packages/core/src/utils/gitDirect.ts (line 282) relies solely on fs.watch against .git/logs/HEAD. There is no polling fallback. When the filesystem doesn't deliver watch events (NFS, FUSE, overlayfs, or when the watcher errors out), the branch name goes stale with no recovery path.

One additional detail worth noting: the watcher.on('error') handler (line 342) permanently deletes the watch entry from repoBranchWatches, so after any watcher error the branch display will never auto-update again for that session — not just miss a single event.

And yes, useGitBranchName (packages/cli/src/ui/hooks/useGitBranchName.ts) depends only on [cwd], so /clear or any other command that doesn't change the working directory won't trigger a re-read.

Suggested fix direction:

A lightweight polling fallback inside watchRepoBranch seems like the cleanest approach — something like a 5–10 second interval that calls resolveBranchName and fans out to subscribers only when the value actually changes. This keeps the existing fs.watch fast-path for local filesystems while guaranteeing eventual consistency everywhere else. The interval should be cleaned up in the disposer alongside the watcher.

Alternatively (or additionally), exposing a manual refresh() from the hook and calling it on /clear and message submission would cover the "user knows something changed" case at zero steady-state cost.

Marking this as a valid bug. A PR implementing either approach would be welcome.