Skip to content

Re-enable progress bars when CLI output mode is explicitly human - #4879

Closed
xbsheng wants to merge 1 commit into
huggingface:mainfrom
xbsheng:fix-output-human-progress-bars
Closed

Re-enable progress bars when CLI output mode is explicitly human#4879
xbsheng wants to merge 1 commit into
huggingface:mainfrom
xbsheng:fix-output-human-progress-bars

Conversation

@xbsheng

@xbsheng xbsheng commented Sep 11, 2026

Copy link
Copy Markdown

Fixes part of #4860.

Problem

Output.set_mode() disables progress bars for any non-human mode but never re-enables them:

def set_mode(self, mode: OutputFormat = OutputFormat.auto) -> None:
    if mode == OutputFormat.auto:
        mode = OutputFormat.agent if is_agent() else OutputFormat.human
    self.mode = mode
    if mode != OutputFormat.human:
        disable_progress_bars()

In an agent-detected session (the current auto detection flags every Warp terminal, see #4860), the CLI starts with auto -> agent and progress bars are disabled. A later explicit hf ... --format human keeps them off: set_mode(human) only changes self.mode, it never calls enable_progress_bars().

Change

  • src/huggingface_hub/cli/_output.py: set_mode(human) now calls enable_progress_bars().
  • tests/test_cli_output.py: new test asserting set_mode(AGENT) disables and set_mode(HUMAN) re-enables the global progress-bar state.

This is independent of the auto-detection fix and works without any TTY sniffing.


Note

Low Risk
Small CLI output-mode change with no auth, data, or API impact; only affects global tqdm/progress-bar visibility.

Overview
Fixes progress bars staying off after switching the CLI to human output. Output.set_mode() already called disable_progress_bars() for non-human modes (agent, json, quiet) but did not turn them back on when mode became human—so a session that started in agent/auto could keep bars disabled even with hf ... --format human.

set_mode() now calls enable_progress_bars() when the resolved mode is human, mirroring the existing disable path. A new test checks agent → human toggles the global progress-bar flag and restores state in teardown.

Reviewed by Cursor Bugbot for commit d9e7583. Bugbot is set up for automated code reviews on this repo. Configure here.

`Output.set_mode()` disables progress bars for any non-human mode but never
re-enables them. In an agent-detected session (e.g. a Warp terminal, see
huggingface#4860), the CLI starts in `auto` -> agent, bars
get disabled, and a later explicit `--format human` keeps them off. This is
independent of the auto-detection fix: only enables progress bars when the
user explicitly asks for human output.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit d9e7583. Configure here.

if mode != OutputFormat.human:
disable_progress_bars()
else:
enable_progress_bars()

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Human mode warns when bars disabled

Low Severity

set_mode now calls enable_progress_bars for every human-mode resolution, including Output construction and auto detection. That helper emits a UserWarning when HF_HUB_DISABLE_PROGRESS_BARS is set, so a normal hf command writes a warning to stderr even though bars were already intentionally disabled.

Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit d9e7583. Configure here.

@Wauplin

Wauplin commented Sep 11, 2026

Copy link
Copy Markdown
Collaborator

closing in favor of #4878

@Wauplin Wauplin closed this Sep 11, 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