Claude Code 2.1.252

在部分 Mac 上，跑 Bash 指令（在終端機裡直接下給電腦的文字命令）會突然失敗，畫面丟出一句 task output swap refused (tasks dir moved or linked)。癥結在存放任務輸出的 tasks 目錄：它如果被移動過，或被換成一個指向別處的連結，Claude 就認不得這個位置，於是拒絕把跑完的結果放回去，整條指令跟著失敗。這次修掉了這個情況，目錄搬過家也好、改成連結也好，指令都能照常跑完。

你在一個新專案裡按下「always allow」（總是允許），想省掉之後每次都被問一次的麻煩，結果下一次做同樣的動作，同一個確認又跳出來。問題在於這個決定要寫進專案裡的 .claude/settings.local.json，而當專案還沒有這個檔案時，你的選擇沒有地方落腳，按了跟沒按一樣。現在即使專案裡還沒有這個檔案，「always allow」也存得住，同一件事不會再問你第二次。

由 Claude Desktop 或 VS Code 主持的 Remote Control（從另一台裝置接手操作同一段對話）碰過一樣的狀況：當連往 claude.ai 的連線變差時，工具明明已經跑完，畫面卻要停上好幾分鐘才有反應。做完的消息傳不回來，你這頭只能等，也分不清它是還在跑，還是已經掛掉。這次把這個情形修掉，連線不穩的時候，工具一結束就會反映到畫面上。

背景任務失敗的時候，會把錯誤內容整包送回對話裡給你看。偏偏有些失敗吐出來的量大得驚人，磁碟塞滿時 git 報的錯就是一個例子。這種通知一塞進對話，整包內容就會超過 API 請求的大小上限，也就是一次能送出去的資料量天花板，於是對話直接卡死在那裡。現在超大的失敗輸出不會再把請求撐破，任務失敗照樣通知你，對話也還走得下去。

On some Macs, Bash commands would suddenly fail with task output swap refused (tasks dir moved or linked). The sticking point was the tasks directory where command output is parked: if that directory had been moved, or replaced with a link pointing somewhere else, Claude no longer recognized the spot, refused to swap the finished output back in, and the whole command went down with it. That case is now fixed, so the command runs to the end whether the directory moved house or turned into a link.

You hit "always allow" in a fresh project to stop being asked the same thing every time, and the very next time you do that action, the same prompt shows up again. The decision has to be written into the project's .claude/settings.local.json, and when the project does not have that file yet, your choice had nowhere to land, so clicking it changed nothing. Now "always allow" sticks even in a project without that file, and the same question stays away.

Remote Control sessions hosted by Claude Desktop or VS Code ran into the same thing: when the connection to claude.ai was degraded, a tool had actually finished, yet the session sat still for minutes before anything moved. The news of completion never made it back, so you waited without knowing whether it was still working or had died. That stall is now fixed, and on a shaky connection the session reacts as soon as the tool ends.

When a background task fails, the error output is sent back into the conversation for you to read. Some failures produce a staggering amount of it; git errors on a full disk are one example. Once such a notification was packed into the conversation, the whole thing went past the API request size limit, the ceiling on how much data can be sent in one go, and the conversation was stuck there. Very large failure output no longer bursts the request, so a failed task still notifies you and the conversation keeps going.