Skip to content

fix(tui): use consistent colors for CLI-only commands - #2490

Merged
aidandaly24 merged 1 commit into
aws:refactorfrom
aidandaly24:fix/tui-cli-only-command-colors
Sep 30, 2026
Merged

aidandaly24 merged 1 commit into
aws:refactorfrom
aidandaly24:fix/tui-cli-only-command-colors

Conversation

@aidandaly24

Copy link
Copy Markdown
Contributor

Description

CLI-only commands are selectable in the TUI but their names were gray. Give every command name the same styling: white when idle and cyan when highlighted.

  • Remove the CLI-only color branch and the unused rendering-only Option.cliOnly field.
  • Preserve command grouping, routing, help fallback, descriptions, and selection behavior.
  • Add an ANSI-enabled regression test covering root and nested menus without changing the existing plain-text screen tests.

Screenshot

Captured from the updated CLI with the TUI harness at 100 columns by 30 rows. feedback, config, and update use the same white labels as the resource commands.

CLI-only commands use the same white labels as other commands

Related Issue

Not applicable. No issue created for this small UX fix.

Documentation PR

Not applicable. No commands or configuration changed.

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Documentation update
  • Other (please describe):

Testing

  • I ran bun test
  • I ran the relevant end-to-end tests with bun run test:e2e, or explained why they are not applicable
  • I ran bun run typecheck
  • I ran bun run lint:check
  • I ran bun run format:check
  • I ran bun run build
  • If I modified src/assets/, I updated affected snapshots with bun test <test-file> --update-snapshots and committed them

bun test: 3,950 passed, 0 failed. Focused menu and CLI-only navigation tests: 133 passed, 0 failed. Typecheck, lint, formatting, and build passed.

Real-AWS end-to-end tests are not applicable: this change only affects menu label styling. The updated CLI was launched and visually checked through the TUI harness.

Checklist

  • I have read the CONTRIBUTING document
  • I have added any necessary tests that prove my fix is effective or my feature works
  • I have updated the documentation accordingly
  • I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
  • My changes generate no new warnings
  • Any dependent changes have been merged and published

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

@github-actions github-actions Bot added the size/s PR size: S label Sep 30, 2026
@agentcore-devx-automation agentcore-devx-automation Bot added agentcore-harness-reviewing AgentCore Harness review in progress claude-security-reviewing Claude Code /security-review in progress labels Sep 30, 2026
@agentcore-devx-automation

Copy link
Copy Markdown
Contributor

Claude Security Review: no high-confidence findings. (run)

@agentcore-devx-automation agentcore-devx-automation Bot removed the claude-security-reviewing Claude Code /security-review in progress label Sep 30, 2026
@aidandaly24
aidandaly24 merged commit 238e54e into aws:refactor Sep 30, 2026
22 of 23 checks passed

@agentcore-devx-automation agentcore-devx-automation Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

AgentCore Harness Review

Verdict: Looks good

Small, focused fix: drops the muted color for CLI-only entries so they render like other menu items, and removes the now-unused cliOnly field from Option. The only remaining use of the cliOnly local at RouterScreen.tsx:148-149 is section placement, which is still correct.

The new test is a nice approach — spawning a child process with FORCE_COLOR=3 to bypass the global FORCE_COLOR=0 set in src/testing/setup.ts (only preloaded for bun test) is a reasonable way to assert on ANSI output without disturbing the plain-text frame assertions used elsewhere. Since bun test's process.execPath is bun, the --eval script's TS/ESM/top-level-await works.

Minor nit (not blocking): on failure the test only asserts result.status === 0 without surfacing result.stderr, which will make future debugging harder if it ever regresses. Not worth blocking on.

Nothing else to flag — no new telemetry needed (bug fix, not a feature), and the test avoids mocking entirely by rendering through the real Root.

@agentcore-devx-automation agentcore-devx-automation Bot removed the agentcore-harness-reviewing AgentCore Harness review in progress label Sep 30, 2026
@codecov-commenter

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.39%. Comparing base (04b45c3) to head (ac434ef).
⚠️ Report is 1 commits behind head on refactor.

Additional details and impacted files
@@             Coverage Diff              @@
##           refactor    #2490      +/-   ##
============================================
- Coverage     97.39%   97.39%   -0.01%     
============================================
  Files           642      642              
  Lines         46807    46801       -6     
============================================
- Hits          45590    45584       -6     
  Misses         1217     1217              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@github-actions

Copy link
Copy Markdown
Contributor

Thanks for the report, @codecov-commenter — feedback like this is exactly
how we catch the things we missed. Because this PR is already
closed, the team won't see follow-up comments here.

Would you mind opening a new issue so we can track it properly?
https://github.com/aws/agentcore-cli/issues/new/choose

If this is a security issue, please report it privately via
https://aws.amazon.com/security/vulnerability-reporting/ instead
of a public issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size/s PR size: S

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants