AlexXXXX

啊，原来不支持 md 格式啊，我在你的 github 项目上提了 issue 。

# Corterm Worker 模式下 shim 递归 fork 导致 EAGAIN

## 环境

- macOS Sonoma 14.x / Apple Silicon
- Claude Code 2.1.139
- Corterm 最新版（通过官方安装脚本）
- 手机端 Cortex Terminal

## 问题描述

在手机端通过 Cortex Terminal 执行 `Claude` 时报错：

```
cortap: failed to start '/Users/<user>/.corterm/shims/claude':
An error occurred trying to start process '/Users/<user>/.corterm/shims/claude'
with working directory '/Users/<user>/project'.
Resource temporarily unavailable
```

初次安装配置后使用正常，后续某次 Worker 重启后开始复现，此后 100% 必现。

## 根因

shim 和 cortap 之间形成递归 fork：

```
用户输入 claude
→ zsh PATH 解析到 shim (~/.corterm/shims/claude)
→ shim exec cortap claude
→ cortap (worker 模式) 解析 "claude" → PATH 中找到的还是 shim
→ 再次 exec shim → exec cortap → ...
→ 内核拒绝分配新进程，返回 EAGAIN
```

zdotdir 的 `.zshrc` 有一段强制把 shims 目录插到 PATH 最前面的逻辑：

```bash
if [[ -n "$CORTERM_SHIMS_DIR" && -d "$CORTERM_SHIMS_DIR" ]]; then
export PATH="$CORTERM_SHIMS_DIR:$_corterm_path"
fi
```

这导致 cortap 在 Worker PTY 内部解析被 wrap 的命令时，永远只能找到 shim 自身而不是真实二进制。

## 临时修复

修改 shim 脚本，在 Worker PTY 环境下直接 exec 真实二进制：

```bash
#!/bin/sh
REAL_CLAUDE="$HOME/.local/bin/claude"
if [ "$XPC_SERVICE_NAME" = "com.corterm.worker" ] || [ -n "$CORTERM_SESSION_ID" ]; then
exec "$REAL_CLAUDE" "$@"
else
exec "$HOME/.corterm/cortap" claude "$@"
fi
```

然后 `chflags uchg` 锁定防止 Worker 重启时覆盖。

## 建议

1. **加递归保护**：shim 里检测环境变量（比如 `_CORTAP_ACTIVE=1`），cortap 启动前 export 这个变量，shim 检测到就直接 exec 真实路径。这是最基本的 wrapper 设计模式。

2. **cortap 不要通过 PATH 解析被 wrap 的命令**：应该用配置文件或硬编码记录真实二进制的绝对路径，否则 PATH 里有 shim 就一定会循环。

3. **错误信息需要改善**：fork bomb 到 EAGAIN 时，cortap 应该记录它尝试启动的路径、当前 PATH 值，以及是否检测到快速重复 fork 。现在用户看到的只有内核错误，完全无法定位问题。

4. **zdotdir 的 PATH 注入应区分场景**：如果当前已经在 cortap 管理的 session 内（比如检测 `XPC_SERVICE_NAME` 或自定义变量），就不应该再把 shims 插到 PATH 里。

5. **不要静默覆盖用户修改过的 shim**：至少做个 checksum 对比，或提供配置项跳过覆盖。

## 误导性

这个 bug 特别难查的原因是 `Resource temporarily unavailable` 指向资源耗尽，正常人的第一反应是去查 jetsam 线程限制、maxproc 、PTY 数量、文件描述符这些系统级限制。实际上是递归 fork 在几毫秒内就把配额打满了，在任何监控工具里看不到进程堆积的痕迹。如果 cortap 有一行日志打印它解析到的路径，这个问题 5 分钟就能定位。

666 老哥，一直在找这样的产品，无痛把终端操控 CC 的体验搬到手机上。还得得推广一下啊，算法平台推给 vibe coding 的人群

ecco 的球鞋不挤脚 夏天也可以穿

不准的 基本上就是看你最近几次的表达方式

claude 替你们总结一下
---
回复里几个有代表性的观点：

1. lscho (#2) — 主流大模型有"情绪模块"，暴躁对话会让模型把权重倾斜到安抚情绪
上，任务质量可能下降
2. yidinghe (#4) — AI 会模仿情绪，宣泄情绪 =
浪费算力在情绪处理上，不带情绪最好
3. JustGoGoGO (#6) —
引用研究说辱骂/客气对输出有影响但不决定性，几个百分点的差异，可信度也存疑
4. www12222 (#10) — 最实用建议：prompt
压缩、减少口语化、多用技术术语、讲不清的让模型复述确认

---
我的判断：这个讨论大方向有道理，但部分表述不准确。

核心事实是：

- 大模型没有情绪，但确实会模式匹配对话风格。你用攻击性语言，模型会分配更多
token 在"安抚/道歉/解释"上，而不是专注解决问题——这不是"情绪"，是 RLHF
训练的结果。
- "情绪模块"这个说法不对，没有独立的情绪子系统。但效果上类似：辱骂式 prompt
确实会轻微劣化输出质量，原因是模型在 response 中需要处理更多社交信号。
- 最有价值的是 #10 的建议：压缩 prompt 、技术化表达、用模型的术语体系、不确定
的需求让它复述。这比"礼貌"本身更影响输出质量。
- 说"请"和"谢谢"几乎零成本，不会帮助也不会伤害。但冗长的情绪化措辞会稀释核心
指令，这才是真正的问题。

简言之：与其纠结礼不礼貌，不如关注指令的清晰度和信噪比。清晰 > 礼貌 > 粗鲁。

夸，夸也算 token

看我这个 https://github.com/PCPrincipal67/claude-code-hooks-sound-system
Claude Code Hooks 提示音系统 - 通过声音反馈感知 AI 工具执行状态

你说的如果是命中缓存，最多按小时算，短的 5 分钟就清空了。在想啥呢，那是实时加载到运算运存里的，不清空那不炸了吗。不是真电脑上的缓存。