[FEATURE] Add --no-ansi flag for screen reader accessibility

[tykihl]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

I am totally blind and use a screen reader to access Claude Code.

I would like to request an improvement to Claude Code regarding the terminal output. The content displayed on screen contains many ANSI formatting characters, which cause fluttering sounds when my screen reader reads the screen. This creates significant accessibility challenges for blind users.

Adding a command-line flag such as --no-ansi to start Claude Code without ANSI formatting characters would greatly improve the experience for screen reader users.

Thank you for your consideration.

Proposed Solution

.

Alternative Solutions

.

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

.

Additional Context

.

[github-actions]

Found 3 possible duplicate issues:

1. [FEATURE] Add a --screen-reader mode for better accessibility with NVDA and JAWS #11002
2. Screen Reader Accessibility for Unicode Symbols #247
3. Accessibility: Add option to disable time elapsed/progress indicators for screen readers #10340

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[tykihl]

There are many similar issues, and is still not any solution!

[raivisdejus]

I have created a Claude Code plugin that can announce permission prompts and last sentence from Claude in a conversation. It works with all major screen readers (JAWS, NVDA, Orca and Voiceover) on all major platforms (Windows, Linux, Mac), has fallback to a system speech synthesis engine.

Check it out https://github.com/raivisdejus/claude-code-plugins

My experience with assistive technologies is limited, feedback from real users would be appreciated.

[davidnegley]

Additional Use Case: GitHub Actions CI/CD Logs

I'd like to add another use case for the --no-ansi flag: clean logs in CI/CD environments, specifically GitHub Actions.

The Problem

When using the claude-code-action in GitHub Actions workflows, the Claude Code installer outputs ANSI escape sequences that get corrupted in the GitHub Actions log viewer. This results in garbled, unreadable text:

Installing Clude Cde nive build2.1.25...
Seting uplauncher and shellintegration.
✔Clade Code successfullyinstalled!
Lcation: ~/.local/bin/claud

Instead of the intended:

Installing Claude Code native build 2.1.25...
Setting up launcher and shell integration.
✔ Claude Code successfully installed!
Location: ~/.local/bin/claude

What We've Tried

We attempted to disable ANSI output by setting standard environment variables:

• TERM=dumb at the job level
• NO_COLOR=1 at the job level

However, the Claude Code installer doesn't respect these conventions, and the output remains garbled in GitHub Actions logs.

Why This Matters

• Log readability: CI/CD logs are essential for debugging and monitoring
• Professional appearance: Garbled text looks unprofessional in build logs
• Accessibility: As mentioned in the original issue, this also affects screen reader users
• Standard practice: Most modern CLI tools respect NO_COLOR and TERM environment variables

Proposed Solution

A --no-ansi flag (or respecting NO_COLOR/TERM environment variables) would solve this for:

1. Screen reader accessibility (original use case)
2. CI/CD environments (this use case)
3. Any other environments where ANSI codes cause display issues

This would align Claude Code with industry best practices - see https://no-color.org/ for the standard many tools follow.

Related Issue

I've also reported this specific GitHub Actions issue at claude-code-action#882 for action-specific solutions.

Thanks for considering this feature request!

[valters]

I am installing Claude Code in a Dockerfile, built with docker build --progress=plain setting. The output of installer is unreadable:

#22 [base 10/14] RUN /tmp/claude-install.sh &&     ${HOME}/.local/bin/claude --version
#22 8.266 Setting up Claude Code...
#22 9.750 
✔ Claude Code successfully installed!        
#2                     s      i   e            .  c   b       o     y    PATH. Run:
#2Version: 2.1.42
#2    .       h                              i  $    "     y      e    o  ig file &&
#2L cation: ~/.local/bin/claudconfig file
#22 20.10 
#22 20.10 
#22 20.10   Next: Run claude --help to get started
#22 20.10 
#22 20.10 ⚠ Setup notes:
#22 20.10   • Native installation exists but ~/.local/bin is not in your PATH. Run:
#22 20.10 
#22 20.10   echo 'export PATH="$HOME/.local/bin:$PATH"' >> your shell config file &&
#22 20.10   source your shell config file
#22 20.10 
#22 20.10 
#22 22.13 
#22 22.20 ✅ Installation complete!
#22 22.20 
#22 22.59 2.1.42 (Claude Code)
#22 DONE 22.7s

The installer should detect it is running in environment where the escape sequences are not effective.

[JacquelineDMcGraw]

I've been working on Claude A11y– it makes AI chat interfaces actually usable with screen readers. I started with Claude's tools, then expanded to ChatGPT, Gemini, and Copilot. It includes a Chrome extension, a VS Code extension, and a CLI wrapper that strips ANSI formatting. Would love feedback and feature improvements as I am actively developing this:
https://github.com/JacquelineDMcGraw/claude-a11y

[vylasaven]

I've been following this thread and built an open-source tool that addresses the output formatting side of these problems: claude-sonar.

I've been using Claude Code like it's a religion for the past year, and reading this thread honestly horrified me. The tool output is already spammy just visually reading it — I can't imagine what that experience is like through a screen reader. So I built this.

It uses Claude Code's hooks system to intercept tool output and reformat it into screen-reader-friendly summaries. Instead of raw JSON or walls of code, you get concise announcements like "Edited auth.ts, changed login function" or "npm test failed, 47 passed, 2 failed."

What it does:

• 14 tool formatters — tailored summaries for Bash, Edit, Read, Write, Grep, Glob, etc.
• Optional TTS — spoken announcements via say (macOS) or spd-say (Linux)
• Earcon sounds — short audio cues (chime for test pass, thud for test fail, etc.)
• Code summarization — when reading/editing files, announces function and class names instead of raw code
• Significance filtering — suppresses noisy routine events, highlights important ones
• Configurable verbosity — from compact (minimum output) to full detail

What it doesn't solve:

• The TUI rendering/NVDA freeze issues described in [FEATURE] Add a --screen-reader mode for better accessibility with NVDA and JAWS #11002. That's a deeper problem in how Claude Code renders to the terminal — hooks can't fix that.
• The box-drawing characters and --no-ansi request. Those need upstream changes in Claude Code itself.

This is complementary to @raivisdejus's plugin — their approach talks directly to screen reader APIs (JAWS, NVDA, Orca, VoiceOver), while claude-sonar focuses on reformatting the tool output itself into something that makes sense when spoken.

Install: npm install -g claude-sonar && claude-sonar setup

A note on what this is: I'm putting this out as a seed project for the community, not something I plan to actively maintain long-term. It's MIT-licensed, has 545 tests, full docs, and a CLAUDE.md so that Claude Code itself understands how to work on it — the intended workflow is to use AI-assisted development to contribute. My hope is that people who actually live with screen readers daily will fork this and shape it into what they need. I'll try to respond to bug reports, but this is meant to be yours.

There may be bugs — the scaffolding is solid but I'm not a screen reader user, so the output quality needs real-world feedback. There's a dedicated screen reader feedback template for reporting output that sounds wrong or confusing.