abtop会话发现揭秘：如何用ps+lsof定位运行中的Claude Code会话并增量读取18MB JSONL

abtop会话发现揭秘如何用pslsof定位运行中的Claude Code会话并增量读取18MB JSONL【免费下载链接】abtopLike htop, but for AI coding agents. Monitor Claude Code Codex CLI sessions, tokens, context window, rate limits, and ports in real-time.项目地址: https://gitcode.com/gh_mirrors/ab/abtopabtop 是一款面向 AI 编码代理的终端监控工具类似 htop/btop它能实时发现所有正在运行的 Claude Code、Codex CLI 与 OpenCode 会话。本文将揭秘它的会话发现Session Discovery机制先用ps找到 claude 进程再用lsof反查进程打开的文件最终增量读取高达 18MB 的 JSONL 转录文件全程只读、无需任何 API Key。为什么需要会话发现同时跑着 3 个以上 Claude Code 会话时你很难知道哪个会话正在工作、哪个在等待输入每个会话的 Token 消耗与上下文窗口占比哪个会话派生的子进程忘了杀、端口还挂着abtop 的答案是不依赖任何远程接口只从本地进程与文件状态推断一切。整个发现管线分 4 步下面逐步拆解 ️第一步用 ps 定位运行中的 claude 进程会话发现的入口是进程表扫描。abtop 在 src/collector/process.rs 中收集所有进程的pid / ppid / rss / %cpu / commandLinux直接解析/proc/{pid}/stat与/proc/{pid}/cmdline零外部依赖其他平台回退到ps -ww -eo pid,ppid,rss,%cpu,command拿到进程表后find_claude_pids做两件事src/collector/claude.rs过滤出命令行中确实包含claude二进制的 PID剔除 abtop自己派生的claude --print摘要子进程避免监控者监控自己 细节PID 是会被操作系统复用的所以不能只看 PID 是否存活还要校验该 PID 的 command 是否仍然是 claude 进程。第二步用 lsof 反查进程打开了什么文件知道 claude 的 PID 后还需要回答它属于哪个配置目录、哪个会话关键在于每个会话启动时都会在~/.claude/sessions/{PID}.json写一个小文件约 170 字节并在退出时删除。abtop 通过进程 → 打开文件的映射反推配置根目录实现见 src/collector/claude.rs平台实现方式Linux解析/proc/{pid}/fd符号链接macOSlibproc的proc_pidinfoAPIWindowssysinfo读取进程 cwd其他 Unix执行lsof -F ftn -p {pid}并解析输出拿到打开路径后程序会沿路径向上寻找同时包含sessions/和projects/子目录的根即认定为一个 Claude 配置根。找不到时还有多级兜底~/.claude、~/.claude-*多 Profile、配置文件里声明的claude_config_dirs以及 Linux 下从/proc/{pid}/environ读取CLAUDE_CONFIG_DIR环境变量src/collector/claude.rs。第三步解析 sessions/{PID}.json 会话小文件找到配置根后读取sessions/{PID}.json即可获得会话的核心索引。其结构定义在 src/model/session.rs{ pid: 7336, sessionId: 2f029acc-..., cwd: /Users/foo/bar, startedAt: 1774715116826 }四个字段各司其职pid→ 关联进程判断存活状态sessionId→ 定位转录文件{sessionId}.jsonlcwd→ 项目名与 Git 状态startedAt→ 过滤掉旧的转录文件若sessions/{PID}.json直接不存在find_session_file_for_pid会扫描整个 sessions 目录按文件内嵌的pid字段兜底匹配src/collector/claude.rs。第四步增量读取 18MB 的 JSONL 转录文件转录文件位于projects/{编码后的路径}/{sessionId}.jsonl路径编码规则/Users/foo/bar→-Users-foo-bar见 encode_cwd_path。一个长会话可以写到1KB18MB每追加一条消息就多一行 JSON。如果每 2 秒轮询一次都全量读一遍 18MBCPU 和 IO 都会吃不消。abtop 的策略是只读新增的字节parse_transcript_with_previous首次发现全量扫描一遍累计出总 Token、上下文历史等基线数据之后每轮seek到上次记录的new_offset只读文件尾部新增内容增量结果与缓存合并Token 累加、轮数递增、任务状态更新src/collector/claude.rs这套偏移量追读设计有 4 个关键防御不完整的行新字节可能恰好截断在半个 JSON 行中间——解析失败且无换行符时暂缓处理等下一轮补齐src/collector/claude.rs文件缩小/轮转若新长度小于偏移量会话重启、文件被替换偏移量重置为 0 重新全量解析文件被替换用(device, inode)作为文件身份指纹即使新文件更大也能识别出这不是原来那个文件src/collector/claude.rs单行上限 10MB物理上限制读取缓冲防止恶意或损坏的超长行撑爆内存解析出的assistant行提供 Token 用量input_tokens cache_read_input_tokens即当前上下文大小user行提供版本号与 Git 分支tool_use内容块则还原出当前正在执行的任务比如Edit src/main.rs。边界情况/clear、多 PID 与陈旧缓存真实场景比理想情况更棘手/clear清空上下文Claude Code 会铸造新的sessionId和新的.jsonl但不重写sessions/{PID}.json导致索引里的 sid 过期。abtop 通过扫描项目目录中 mtime 最新的 jsonl 来认领真实存活的会话find_live_session_id同一目录多个 claude 进程无法判断新 jsonl 归谁所有此时主动禁用sid 覆盖宁可显示旧数据也不串数据陈旧缓存驱逐/clear后旧 sid 离开活跃集合其缓存含过期的 Token 计数器在下一轮 tick 即被清除保证计数永远跟随真实会话最终效果一屏掌握所有会话状态以上机制每 2 秒一轮进程树、转录追读端口扫描与 Git 状态每 10 秒一轮错开执行避免卡顿。状态判定是多信号融合的子进程 CPU 活跃 → 执行中tool_use未应答 → 执行中最新一条是用户 prompt → 思考中否则等待输入。上下文窗口百分比则由模型硬编码的窗口大小如 200K除以最后一轮input_tokens cache_read得出超过 80% 黄色预警、90% 红色告警还能自动检测上下文压缩compaction事件完整的设计文档可参考仓库内的 AGENTS.md其中Data Sources一节详细列出了全部 10 类本地数据源。总结步骤手段解决的问题1ps//proc扫描找到所有 claude 进程并校验 PID 防复用2lsof/ fd 反查从打开文件反推配置根目录3读取sessions/{PID}.json拿到 sessionId 与 cwd 索引4偏移量增量追读 JSONL18MB 转录文件只读新增字节核心思路值得借鉴把进程还活着 打开了什么文件 文件尾部增量三者结合就能在完全只读的前提下实时还原出每个 AI 编码代理会话的完整状态。想动手体验的话cargo install abtop后运行abtop即可看到效果。【免费下载链接】abtopLike htop, but for AI coding agents. Monitor Claude Code Codex CLI sessions, tokens, context window, rate limits, and ports in real-time.项目地址: https://gitcode.com/gh_mirrors/ab/abtop创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考