Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[FEATURE]: Support /color session highlighting

Open
#452 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
22/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
cli

Research direction

Start by checking whether the pinned SDK's session-info type or any event exposes a session color; the issue says it does not, so confirm that before touching code. Then trace how the bridge passes session data into the Rust UI and pick the composer border or session-name area to render the color. Done means the color changes on screen and resets or persists correctly across /clear, session switching and resume, with error and warning colors left intact.

Written by the indexing model from the issue text.

Description

area: tui help wanted type: feature
Problem Statement

/color runs in the SDK session, but claude-rs keeps its default UI colors. The reply-delivery fix in #444 makes the acknowledgement visible without applying the requested color to our interface. A visible session accent would help tell sessions apart.

This is the visual-color feature explicitly left out of #438, separate from command replies and live session-name updates.

Proposed Solution

Make /color change a small, clearly defined session highlight in claude-rs, using our existing UI components. Keep error and warning colors meaningful. A global theme preference is outside this issue's scope.

Help wanted with the SDK integration and implementation:

  • Establish a supported SDK API or event for reading and synchronizing the current session color. The pinned SDK's public session-info type does not expose a color field; verify the available integration before implementing it.
  • Choose the affected region, such as the composer border or session-name highlight, and carry the authoritative color through the bridge/Rust contract to rendering.
  • Support the advertised color choices, default, and bare /color behavior. Verify how color behaves after /clear, session switching, and resume rather than assuming session scope means either persistence or automatic reset.
  • Keep one authoritative color source. Do not parse acknowledgement text or read private Claude Code files.
  • Verify the actual rendered change, reset behavior, and session transitions. A success message alone does not establish that the feature works.
Alternatives Considered
  • Keep forwarding the command and document that its color has no visual effect in claude-rs. This leaves the acknowledgement disconnected from our display.
  • Add a saved app-wide highlight preference. That is a separate feature from the active SDK session's /color command.
Checklist
  • I have searched existing issues and discussions to ensure this is not a duplicate
Dominant language
Rust
Stars
261
Forks
57
Avg merge
10h 42m
Merged PRs (30d)
58

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from srothgan/claude-code-rust

All issues in srothgan/claude-code-rust

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.