Claude Code Tools Files

v1.23.2 fixes the actual cause of the >trim timeouts that v1.23.1 made visible: >trim was spending its whole time budget rebuilding the search index, not trimming.

>trim was paying for a full index scan

Every aichat command runs an incremental index refresh first, walking every session file in both agent homes. On the machine where this was found that is 13,656 files — about 4.5 seconds when there is essentially nothing to do, and considerably longer with a backlog.

trim-in-place was paying that on every call, even though it never queries the index; it resolves a path directly. And it runs under the >trim hook's time budget. So the budget went on indexing:

With any real backlog the scan ran far longer — 30 seconds and more was observed — which is what killed >trim outright.

Why it looked like a big-session problem, and wasn't

Every symptom pointed the wrong way until the timing was measured:

• The failures only ever showed up on large sessions, so the transcript looked guilty. It wasn't: a one-line transcript was just as slow, because the cost is the 13.6k-file walk, not the file being trimmed. Large sessions correlated only because they are the ones you reach for >trim on, and they are usually live and churning — which is exactly what gives the indexer something to do.
• aichat --version stayed instant, which made the CLI look healthy. --version exits before the group callback that does the indexing.
• Running the same trim through aichat resume worked fine every time. It pays exactly the same indexing cost — but interactively there is no timeout, so it just feels like a slow start.

The fix

trim-in-place now skips the index refresh, joining port and resolve. Trimming rewrites the session file anyway, so indexing its pre-trim content immediately beforehand was wasted work twice over. The next aichat command picks the trimmed file up normally through its changed size and mtime.

Sessions you trim stay searchable; nothing about the index contract changes.

Keep an eye on

If >trim ever times out again, the diagnostic added in v1.23.1 still applies: the message names the budget that expired, the transcript, which aichat your PATH resolved to, a copy-pasteable command to reproduce it, and whatever the CLI printed first. That diagnostic is what located this bug, on its first real use.