Skip to content

feat(cli): add approval-mode to status line presets - #7370

Closed
Mikedu1988 wants to merge 2 commits into
QwenLM:mainfrom
musrice:feat/statusline-approval-mode
Closed

feat(cli): add approval-mode to status line presets#7370
Mikedu1988 wants to merge 2 commits into
QwenLM:mainfrom
musrice:feat/statusline-approval-mode

Conversation

@Mikedu1988

@Mikedu1988 Mikedu1988 commented Jul 21, 2026

Copy link
Copy Markdown

Body

Problem

The mode indicator (e.g. YOLO 模式 (Shift + Tab 切换)) is rendered in the footer's bottom hint row (leftBottomContent). During task execution, this row is replaced by streaming hints like Enter to steer · Ctrl+Q to queue, making the current approval mode completely invisible while work is in progress.

Solution

Add approval-mode as a configurable status line preset item. The status line row is always visible and independent of the hint row's priority chain, so the mode name remains visible at all times — including during streaming, tool execution, and confirmation prompts.

Changes

  • statusLinePresets.ts: New approval-mode preset item with i18n-translated labels (YOLO mode, plan mode, Auto mode, etc.)
  • useStatusLine.ts: Passes showAutoAcceptIndicator to the preset data builder and tracks it as a reactive trigger so the status line updates immediately on mode switch
  • statusLinePresets.test.ts: Two new test cases (renders mode label, omits when undefined)

Usage

Users can add approval-mode to their status line via /statusline or settings.json:

{
  "ui": {
    "statusLine": {
      "type": "preset",
      "items": ["project-name", "git-branch", "model-with-reasoning", "context-used", "approval-mode"]
    }
  }
}

Result: → spider-man · git:(main) · qwen3.8-max-preview · 1.0m Context 3.5% used · YOLO mode

Verification

  • ✅ TypeScript typecheck passes (tsc --noEmit)
  • ✅ All 20 unit tests pass (including 2 new ones)
  • ✅ Manual testing: mode name visible in status line during task execution

The mode indicator (e.g. 'YOLO mode') was only shown in the footer's
bottom hint row, which gets replaced by task-execution hints like
'Enter to steer · Ctrl+Q to queue' during streaming — making the
current mode invisible while work is in progress.

Add 'approval-mode' as a configurable status line preset item so
users can place the mode name in the always-visible status line row.
The item uses i18n translations and updates reactively when the mode
changes via Shift+Tab.

Closes the UX gap where mode context disappears during task runs.

@qwen-code-ci-bot qwen-code-ci-bot left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR, @Mikedu1988 — the status-line wiring itself looks clean, but I think the problem this sets out to solve has already been fixed upstream, and I'd want to confirm before we go deeper.

The motivation is that the mode indicator "gets replaced by task-execution hints like 'Enter to steer · Ctrl+Q to queue' during streaming — making the current mode invisible while work is in progress." That gap was closed by #7219 (fix(cli): show mode indicator alongside steering hint during streaming, merged 2026-07-19), and that fix is already in this PR's own base — the branch merges current main (merge-base is today's main HEAD).

In the current Footer.tsx, the StreamingState.Responding branch renders the mode right alongside the steering hint rather than replacing it:

) : uiState.streamingState === StreamingState.Responding ? (
  <Text color={theme.text.secondary}>
    {t('Enter to steer · Ctrl+Q to queue')}
    {showAutoAcceptIndicator !== undefined && (
      <>
        {' · '}
        <AutoAcceptIndicator approvalMode={showAutoAcceptIndicator} />
      </>
    )}
  </Text>

…and in every other state where the mode is defined, <AutoAcceptIndicator> is shown on its own. So as of current main the mode stays visible throughout a task run. There's no linked issue and no before/after reproduction showing a state where it still disappears — without one, the motivating gap is a hypothesis the current code already disproves.

Could you provide a concrete reproduction against current main — a specific state or scenario where the mode is actually invisible? If there's a different use case driving this (e.g. you specifically want the mode available as a configurable status-line item regardless of the footer), let's reframe the PR around that real use case rather than a gap that's already closed — and that's ultimately a call for the maintainer on whether the extra preset item is wanted.

One note for if this does move forward: the new getApprovalModeLabel in statusLinePresets.ts re-implements the mode→label switch that already lives in AutoAcceptIndicator.tsx (same five cases, same i18n keys, differing only by the prefix on DEFAULT). Worth extracting a shared helper so the two surfaces don't drift.

中文说明

感谢 @Mikedu1988 的 PR——status-line 的接线本身写得很干净,但我认为这个 PR 想解决的问题已经在上游修复了,深入审查前想先确认一下。

PR 的动机是:模式指示器"在流式输出时被 'Enter to steer · Ctrl+Q to queue' 这类任务提示替换掉,导致任务进行时当前模式不可见"。这个缺口已经被 #7219fix(cli): show mode indicator alongside steering hint during streaming,2026-07-19 合并)修复了,而该修复已经包含在本 PR 自己的 base 里——本分支合并了当前 main(merge-base 是今天的 main HEAD)。

在当前 Footer.tsx 中,StreamingState.Responding 分支会把模式指示器和 steering 提示一起渲染出来,而不是替换它(见上方代码)。而在其它所有模式已定义的状态下,<AutoAcceptIndicator> 会单独显示。所以在当前 main 上,整个任务运行期间模式都是可见的。PR 没有关联 issue,也没有提供 before/after 复现来证明模式在某个状态下仍然会消失——没有复现的话,这个动机只是一个被当前代码已经推翻的假设。

能否针对当前 main 提供一个具体复现——某个模式确实不可见的状态或场景?如果有其它真正的诉求在驱动这个改动(比如你就是希望把模式作为一个可配置的 status-line 项,与 footer 无关),那我们围绕这个真实诉求重新组织 PR,而不是一个已经关闭的缺口——这最终需要 maintainer 判断是否需要这个额外的 preset 项。

另外,如果这个 PR 继续推进:statusLinePresets.ts 里新增的 getApprovalModeLabel 重新实现了 AutoAcceptIndicator.tsx 里已有的 模式→标签 switch(同样五种情况、同样的 i18n key,仅 DEFAULT 的 前缀不同)。建议抽出一个共享 helper,避免两处不一致。

Qwen Code · qwen3.7-max

@Mikedu1988 Mikedu1988 closed this Jul 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants