Claude Code Progress Bar: What task-progress-mod v0.2 Adds

The signal is often buried in the output

Take a test command that prints hundreds of passing cases and then only at the end reports two failures. The full output is useful when you need to debug, but for the first question - did the run pass? - most of it is noise.

You see the same pattern in other places, too:

• Build and test logs: They can repeat the routine "all good" messages while the failure details land at the end.
• Large JSON responses: They may contain hundreds of records when you mostly care about status, totals, and the overall shape.
• Diffs: They can be dominated by repetitive edits, including lockfile churn that hides a small source-code change.
• Short command results: They might already be concise, but they still add another chunk of transcript you have to skim.

The problem isn't that detailed output is useless. It's that "detailed output for debugging" and "quick signal for supervision" are different jobs. You want the full log when you're investigating; you want a short status when you're deciding whether to investigate in the first place.

A task indicator is not an outcome indicator

A progress bar can tell you the agent is moving through a plan. It can't, by itself, tell you what the last tool actually returned. If the agent marks one todo done after an unsuccessful command, the task list and the command result may tell different stories.

A human can catch that by reading the transcript - but the effort grows fast with tool-call volume. Doing that once or twice is manageable. Doing it dozens of times during a larger task becomes its own monitoring job.

That's what task-progress-mod v0.2 tries to fix. It doesn't "guarantee correctness," and it doesn't remove the need to review changes. The goal is simpler: make it cheaper to see the immediate state of the work.

How the summarizer handles different output

The summarizer uses heuristics instead of trying to reproduce every part of a tool result. Per the project description, it handles several common shapes:

• Test and build logs: It reports failure details and pass counts. If something fails, you may see the first failure; if everything is green, you may see how many passed.
• JSON output: It shows a skeleton rather than the full payload. A response with many records might be represented by status, an abbreviated results field, and a total count.
• Diffs: It summarizes changes per file, including additions and deletions, and it can collapse lockfile noise into a count.
• Short output: It prints the content as-is on a single line.

The design choice here is fairly clear: keep a few orientation signals and skip the rest. The line is labeled with the tool name and is meant to match the most recent tool output, so you can connect the summary to what produced it.

Why "fail-open" is a meaningful design choice

The project describes the summarizer as heuristic and fail-open. That's a reasonable approach for a UI layer: if a result doesn't match a known pattern, the safest fallback is to show it in one line rather than block the underlying interaction with a bad or missing summary.

There's a trade-off, though. Heuristics aren't a substitute for full parsing with semantic understanding. A summary can omit context, miss an unusual format, or compress information that actually matters.

So treat the summary as an index into the latest tool activity, not a replacement for inspection. When the command is important, when the summary reports failure, or when the result affects behavior you care about, you still need to look at the full output (and the relevant files) before the agent moves on.

The summary can help reveal plan drift

Because the line always reflects the latest tool output, it can also act as a lightweight "deviation" signal. For example, if the current todo says the agent is writing tests, but the last tool summary indicates unrelated file changes - or a command that doesn't obviously connect - you've got a reason to look closer before the next todo update.

This isn't an automated plan validator. The Mod doesn't decide whether an action is appropriate, and sometimes a seemingly unrelated command is exactly what you need. The practical benefit is the shorter feedback loop: you can spot a mismatch without reading a long transcript from top to bottom.

A practical way to trial it

Instead of judging it based on one tidy test run, try it on a small task that produces a mix of output. For example: ask an agent to inspect a codebase, make a contained change, and run the relevant tests. While you use it, compare the display against a few practical questions:

1. Can you tell what the agent just did? The tool label should help you connect the summary to the action.
2. Does the summary surface outcomes that change your next decision? A pass count, failure name, or file-level diff might be enough to decide whether you need to dig deeper.
3. Does it make plan drift easier to spot? Compare the latest tool result with the current todo - without treating every mismatch as an automatic error.
4. Do you still know when to open the full output? The summary should reduce routine scanning, not discourage investigation when it matters.
5. Does it stay useful with your project's actual commands? Output formats vary. Test with what your team really runs rather than assuming every log matches the examples.

This trial is more useful than asking whether the interface looks cleaner. The real question is whether the extra signal changes how quickly you can supervise the work - without hiding evidence you still need.

Where it fits - and where it does not

The Mod is most helpful when you're supervising agent work across a long sequence of tool calls and you want a quick read on the latest result. It may matter less for short tasks, workflows where you already open everything immediately, or teams that require full structured reporting instead of a compact visual cue.

It also doesn't replace code review, test verification, or security review. A line saying that tests passed doesn't prove the tests cover the right behavior. A short diff summary doesn't tell you whether a change is correct. And a JSON skeleton can omit a record that matters for your specific scenario.

A sensible division of responsibility looks like this:

• Use the progress bar and summary to stay oriented while work is running.
• Use the full output and repository state to verify important results.
• Use your normal review process before merging or deploying changes.

That's the feature's proper role: a human-facing observability aid, not a correctness layer.