【Bug已解决】Error: Raw mode is not supported on the current process.stdin 解决方案1. 问题描述在非交互式环境比如通过脚本调用、CI/CD 流水线、Docker 容器、或者用nohup/放到后台中启动 Claude Code 时很多人会遇到这样的报错程序直接崩溃退出Error: Raw mode is not supported on the current process.stdin, which Ink uses as input stream by default. Read about how to prevent this error on https://github.com/vadimdemedes/ink/#israwmodesupported1.1 常见触发场景在 GitHub Actions / GitLab CI 里直接调用claude 帮我审查这段代码用 Python/Node 的subprocess/child_process以非 TTY 方式启动 Claude Code通过 SSH 远程执行一条命令后立即断开连接没有分配伪终端在 Docker 容器里不带-it参数运行docker run把 Claude Code 输出重定向到文件claude log.txt这个问题在把 Claude Code 当作可编程调用的后台服务、而不是在真实终端里手动敲命令这种场景下特别常见是很多人第一次尝试把 Claude Code 集成进自动化脚本时遇到的第一个拦路虎。2. 原因分析Claude Code 的交互式命令行界面基于 Ink一个用 React 渲染终端 UI 的库构建。Ink 为了实现实时刷新、方向键选择、逐字节读取用户输入这类交互效果需要把标准输入流切换到Raw 模式禁用行缓冲、逐字符读取而不是等用户按下回车才拿到整行内容。问题在于Raw 模式依赖操作系统提供的**TTY伪终端**能力而这项能力只有在真正的交互式终端里才存在运行环境是否有 TTYRaw 模式是否可用本地终端手动敲命令有✅ 可用CI/CD 流水线非交互执行无❌ 不可用docker run无-it无❌ 不可用输出被重定向到文件/管道无❌ 不可用SSH 执行单条命令后断开无❌ 不可用用一张流程图梳理触发链路启动 claude 命令 ↓ Ink 尝试将 process.stdin 切换为 Raw 模式 ↓ 检测当前 stdin 是否为 TTY ├─ 是 TTY → 正常进入交互式界面 └─ 不是 TTY → 抛出 Raw mode is not supported 异常进程退出3. 解决方案方案一使用非交互模式的-p/--print参数最推荐Claude Code 专门为脚本化调用提供了非交互输出模式不会尝试进入 Raw 模式# -p 参数给出一次性指令直接打印结果后退出不进入交互式界面 claude -p 帮我总结一下 src/utils 目录下所有函数的用途 # 结合 --output-format 输出结构化 JSON方便脚本进一步处理 claude -p 检查这段代码有没有明显的安全漏洞 --output-format json这是官方为 CI/CD、脚本调用场景设计的标准用法从根源上避免了对 TTY 的依赖。方案二为容器/远程执行分配伪终端如果确实需要交互式界面比如调试阶段想看到完整的实时渲染效果可以手动分配一个伪终端# Docker加上 -it 参数分配伪终端 docker run -it your-image claude # SSH加上 -t 参数强制分配伪终端 ssh -t userhost claude方案三用script命令伪造一个 TTY 环境在完全没有终端的自动化环境里比如某些老旧的 CI 系统可以用 Linux 自带的script命令伪造一个伪终端script -qc claude -p 生成一份变更日志 /dev/null方案四用pty/node-pty在程序内部包一层伪终端如果是用 Node.js 脚本调用 Claude Code且必须保留交互能力可以借助node-pty库在代码层面模拟一个伪终端const pty require(node-pty); const ptyProcess pty.spawn(claude, [], { name: xterm-color, cols: 80, rows: 30, cwd: process.cwd(), env: process.env }); ptyProcess.onData(data process.stdout.write(data));⚠️风险提示node-pty涉及本地编译node-gyp跨平台部署时需要额外注意编译环境是否完整不建议作为首选方案仅在必须保留完整交互体验时使用。方案五检查是否被日志重定向意外触发有些人是在正常的终端里手动敲命令但因为脚本里带了 output.log 21这类重定向导致 stdin 判断失效# 错误写法重定向了标准输出间接影响了 TTY 检测 claude 帮我看看这个 bug output.log # 正确写法只在确实需要保存日志时用 tee同时保留终端交互 claude 帮我看看这个 bug | tee output.log4. 各方案对比总结方案适用场景推荐指数-p非交互模式CI/CD、脚本调用、批处理任务⭐⭐⭐⭐⭐分配伪终端-it/-t容器/远程调试仍需要交互界面⭐⭐⭐⭐script命令伪造 TTY老旧 CI 系统无法加-it参数⭐⭐⭐node-pty包装Node 程序内需要完整交互能力⭐⭐检查重定向逻辑本地终端误触发的边缘情况⭐⭐⭐5. 常见问题 FAQ5.1 GitHub Actions 里到底应该怎么写标准写法是直接用-p参数不需要任何额外的 TTY 配置- name: Run Claude Code review run: claude -p 审查本次 PR 的改动输出简要意见 --output-format json env: ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}5.2 Windows 上用 PowerShell 调用会不会有一样的问题会。PowerShell 的Start-Process默认也不会分配伪终端同样需要用-p参数或者在原生的 Windows Terminal / PowerShell 窗口里手动交互式运行。5.3 用 Python 的subprocess调用时应该注意什么直接用subprocess.run调用非交互命令即可不需要伪造终端import subprocess result subprocess.run( [claude, -p, 分析这个函数的时间复杂度], capture_outputTrue, textTrue ) print(result.stdout)5.4 为什么本地终端里好好的放到 tmux/screen 里就报错了tmux/screen 本身是支持伪终端的通常不会有这个问题如果报错大概率是在 tmux 会话内部又通过某种脚本方式比如tmux send-keys配合非交互执行间接触发了非 TTY 场景排查时优先确认是否有额外的包装脚本。5.5-p模式下还能使用工具调用读写文件、执行命令吗可以-p只是关闭了交互式 UI 渲染Agent 的工具调用能力文件读写、命令执行、代码编辑完全保留只是所有确认动作会按照配置的权限策略自动处理不会等待终端里的人工确认。5.6 团队里应该统一规范吗建议团队约定任何需要在脚本/CI 里调用 Claude Code 的场景统一使用-p--output-format json避免不同成员各自尝试用奇怪的方式伪造终端环境造成维护成本上升。5.7 排查清单速查表□ 1. 确认调用场景是否本来就该用非交互模式优先切换到 -p 参数 □ 2. Docker 场景检查是否漏了 -it 参数 □ 3. SSH 场景检查是否漏了 -t 参数 □ 4. 检查脚本里是否有意外的输出重定向影响了 TTY 判断 □ 5. Node.js 场景确认是否真的需要完整交互能力能用 -p 就不要上 node-pty □ 6. CI/CD 流水线统一改造为 -p --output-format json 的标准写法6. 总结Raw mode is not supported报错的本质是Claude Code 的交互式 UI 依赖真实 TTY而自动化/非交互场景天然没有 TTY。核心处理思路绝大多数脚本化场景应该直接换用-p非交互模式而不是想办法伪造一个终端环境只有明确需要保留完整交互体验比如容器内调试时才考虑分配伪终端-it/-tnode-pty这类深度包装方案涉及额外的编译依赖作为最后的兜底手段而非首选。最佳实践建议把是否需要真正的交互界面作为设计自动化流程时的第一个判断标准能用非交互模式解决的场景就不要引入伪终端相关的额外复杂度。
【Bug已解决】Error: Raw mode is not supported on the current process.stdin 解决方案1. 问题描述在非交互式环境比如通过脚本调用、CI/CD 流水线、Docker 容器、或者用nohup/放到后台中启动 Claude Code 时很多人会遇到这样的报错程序直接崩溃退出Error: Raw mode is not supported on the current process.stdin, which Ink uses as input stream by default. Read about how to prevent this error on https://github.com/vadimdemedes/ink/#israwmodesupported1.1 常见触发场景在 GitHub Actions / GitLab CI 里直接调用claude 帮我审查这段代码用 Python/Node 的subprocess/child_process以非 TTY 方式启动 Claude Code通过 SSH 远程执行一条命令后立即断开连接没有分配伪终端在 Docker 容器里不带-it参数运行docker run把 Claude Code 输出重定向到文件claude log.txt这个问题在把 Claude Code 当作可编程调用的后台服务、而不是在真实终端里手动敲命令这种场景下特别常见是很多人第一次尝试把 Claude Code 集成进自动化脚本时遇到的第一个拦路虎。2. 原因分析Claude Code 的交互式命令行界面基于 Ink一个用 React 渲染终端 UI 的库构建。Ink 为了实现实时刷新、方向键选择、逐字节读取用户输入这类交互效果需要把标准输入流切换到Raw 模式禁用行缓冲、逐字符读取而不是等用户按下回车才拿到整行内容。问题在于Raw 模式依赖操作系统提供的**TTY伪终端**能力而这项能力只有在真正的交互式终端里才存在运行环境是否有 TTYRaw 模式是否可用本地终端手动敲命令有✅ 可用CI/CD 流水线非交互执行无❌ 不可用docker run无-it无❌ 不可用输出被重定向到文件/管道无❌ 不可用SSH 执行单条命令后断开无❌ 不可用用一张流程图梳理触发链路启动 claude 命令 ↓ Ink 尝试将 process.stdin 切换为 Raw 模式 ↓ 检测当前 stdin 是否为 TTY ├─ 是 TTY → 正常进入交互式界面 └─ 不是 TTY → 抛出 Raw mode is not supported 异常进程退出3. 解决方案方案一使用非交互模式的-p/--print参数最推荐Claude Code 专门为脚本化调用提供了非交互输出模式不会尝试进入 Raw 模式# -p 参数给出一次性指令直接打印结果后退出不进入交互式界面 claude -p 帮我总结一下 src/utils 目录下所有函数的用途 # 结合 --output-format 输出结构化 JSON方便脚本进一步处理 claude -p 检查这段代码有没有明显的安全漏洞 --output-format json这是官方为 CI/CD、脚本调用场景设计的标准用法从根源上避免了对 TTY 的依赖。方案二为容器/远程执行分配伪终端如果确实需要交互式界面比如调试阶段想看到完整的实时渲染效果可以手动分配一个伪终端# Docker加上 -it 参数分配伪终端 docker run -it your-image claude # SSH加上 -t 参数强制分配伪终端 ssh -t userhost claude方案三用script命令伪造一个 TTY 环境在完全没有终端的自动化环境里比如某些老旧的 CI 系统可以用 Linux 自带的script命令伪造一个伪终端script -qc claude -p 生成一份变更日志 /dev/null方案四用pty/node-pty在程序内部包一层伪终端如果是用 Node.js 脚本调用 Claude Code且必须保留交互能力可以借助node-pty库在代码层面模拟一个伪终端const pty require(node-pty); const ptyProcess pty.spawn(claude, [], { name: xterm-color, cols: 80, rows: 30, cwd: process.cwd(), env: process.env }); ptyProcess.onData(data process.stdout.write(data));⚠️风险提示node-pty涉及本地编译node-gyp跨平台部署时需要额外注意编译环境是否完整不建议作为首选方案仅在必须保留完整交互体验时使用。方案五检查是否被日志重定向意外触发有些人是在正常的终端里手动敲命令但因为脚本里带了 output.log 21这类重定向导致 stdin 判断失效# 错误写法重定向了标准输出间接影响了 TTY 检测 claude 帮我看看这个 bug output.log # 正确写法只在确实需要保存日志时用 tee同时保留终端交互 claude 帮我看看这个 bug | tee output.log4. 各方案对比总结方案适用场景推荐指数-p非交互模式CI/CD、脚本调用、批处理任务⭐⭐⭐⭐⭐分配伪终端-it/-t容器/远程调试仍需要交互界面⭐⭐⭐⭐script命令伪造 TTY老旧 CI 系统无法加-it参数⭐⭐⭐node-pty包装Node 程序内需要完整交互能力⭐⭐检查重定向逻辑本地终端误触发的边缘情况⭐⭐⭐5. 常见问题 FAQ5.1 GitHub Actions 里到底应该怎么写标准写法是直接用-p参数不需要任何额外的 TTY 配置- name: Run Claude Code review run: claude -p 审查本次 PR 的改动输出简要意见 --output-format json env: ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}5.2 Windows 上用 PowerShell 调用会不会有一样的问题会。PowerShell 的Start-Process默认也不会分配伪终端同样需要用-p参数或者在原生的 Windows Terminal / PowerShell 窗口里手动交互式运行。5.3 用 Python 的subprocess调用时应该注意什么直接用subprocess.run调用非交互命令即可不需要伪造终端import subprocess result subprocess.run( [claude, -p, 分析这个函数的时间复杂度], capture_outputTrue, textTrue ) print(result.stdout)5.4 为什么本地终端里好好的放到 tmux/screen 里就报错了tmux/screen 本身是支持伪终端的通常不会有这个问题如果报错大概率是在 tmux 会话内部又通过某种脚本方式比如tmux send-keys配合非交互执行间接触发了非 TTY 场景排查时优先确认是否有额外的包装脚本。5.5-p模式下还能使用工具调用读写文件、执行命令吗可以-p只是关闭了交互式 UI 渲染Agent 的工具调用能力文件读写、命令执行、代码编辑完全保留只是所有确认动作会按照配置的权限策略自动处理不会等待终端里的人工确认。5.6 团队里应该统一规范吗建议团队约定任何需要在脚本/CI 里调用 Claude Code 的场景统一使用-p--output-format json避免不同成员各自尝试用奇怪的方式伪造终端环境造成维护成本上升。5.7 排查清单速查表□ 1. 确认调用场景是否本来就该用非交互模式优先切换到 -p 参数 □ 2. Docker 场景检查是否漏了 -it 参数 □ 3. SSH 场景检查是否漏了 -t 参数 □ 4. 检查脚本里是否有意外的输出重定向影响了 TTY 判断 □ 5. Node.js 场景确认是否真的需要完整交互能力能用 -p 就不要上 node-pty □ 6. CI/CD 流水线统一改造为 -p --output-format json 的标准写法6. 总结Raw mode is not supported报错的本质是Claude Code 的交互式 UI 依赖真实 TTY而自动化/非交互场景天然没有 TTY。核心处理思路绝大多数脚本化场景应该直接换用-p非交互模式而不是想办法伪造一个终端环境只有明确需要保留完整交互体验比如容器内调试时才考虑分配伪终端-it/-tnode-pty这类深度包装方案涉及额外的编译依赖作为最后的兜底手段而非首选。最佳实践建议把是否需要真正的交互界面作为设计自动化流程时的第一个判断标准能用非交互模式解决的场景就不要引入伪终端相关的额外复杂度。
