2026年 DeepSeek Harnessのnode-pty更新：Mac再確認

公式リリースで確認できる事実は明確です。v0.1.0-rc.7 は2026年8月17日に公開され、簡易モードにおける持続Bash呼び出しの遅延修正、node-pty 1.2 betaへの更新、PTYのプラットフォーム互換性拡大が記載されています。詳しくはDeepSeek Harness v0.1.0-rc.7の公式リリースを確認してください。

ここで、「互換性が改善された」と「Mac上のすべての端末問題が解消した」は別の話です。公式文面だけでは、対応するmacOSの範囲、長時間処理の安定性、通信切断時の再開動作までは確定できません。

node-pty上流でも、macOS向けのkqueueファイルディスクリプター処理などが更新されています。これは端末層で継続的に修正が行われていることを示しますが、DeepSeek Harnessの全シナリオが同じ結果になる根拠にはなりません。変更内容はnode-ptyの公式リリース履歴で確認できます。

第一段階：交互入力の閉ループ

最初の再確認では、難しい処理を選ばないでください。次の順序で、画面表示と実プロセスの両方を記録します。

• [ ] Bashを起動し、入力文字が画面へ正しく返る
• [ ] 短いコマンドを連続して実行できる
• [ ] 標準出力と標準エラー出力の順序が大きく崩れない
• [ ] 正常終了と異常終了の終了コードを区別できる
• [ ] コマンド終了後に入力待ちへ戻る
• [ ] 取消操作後にシェルや子プロセスが残っていない

確認対象は「表示されたか」だけではありません。入力が受理された時刻、出力が流れ始めた時刻、終了状態が表示された時刻を分けて記録します。モデルの応答待ち、アプリケーション側の処理、PTYの出力処理を一つの遅延として扱うと、原因を取り違えます。

終了コードとシグナルは別の状態です。Node.jsの子プロセス仕様でも、終了時にはコードまたはシグナルを確認でき、killed が真になっても対象プロセスの終了そのものを意味しないと説明されています。取消判定では、Node.jsのchild_process公式仕様に沿って、画面表示だけでなくプロセス状態を確認してください。

長時間タスクでは、カクついた場所を一つに決めつけないことが重要です。少なくとも、次の経路を分けて観察します。

1. BashやPTYから出力が届かない。
2. DeepSeek Harnessの画面更新が遅れる。
3. モデルが次の操作を判断するまで待っている。

例えば、ビルドログが画面に表示されなくても、Mac側のプロセスが処理を続けている場合があります。逆に、画面だけが動いていても、実際の子プロセスが終了していればタスクは継続していません。

一度成功しただけでは、長時間の安定性は証明できません。短い出力、まとまった出力、エラーを含む出力を分け、同じ手順を旧版とrc.7で繰り返してください。

取消処理は、停止ボタンを押したという事実だけで合格にしないでください。Node.jsでは、subprocess.kill() がシグナル送信に成功したことと、子プロセスが実際に終了したことは別に扱われます。シグナル処理の境界はNode.jsのprocess公式仕様にも記載されています。

対話型プログラムを使う運用では、端末機能の境界を確認します。ただし、すべての端末機能を一覧化する必要はありません。DeepSeek Harnessの実タスクで発生するものだけを選びます。

node-ptyは擬似端末をNode.jsから扱うためのライブラリで、macOS、Linux、Windowsを対象にしています。端末として認識させること、読み書き、端末サイズ変更などが主な役割です。機能の範囲はnode-pty公式リポジトリで確認できます。

失敗した場合は、最小の再現環境を残します。対象コマンド、シェル、作業ディレクトリ、macOSのバージョン、DeepSeek Harnessのビルド、node-ptyの解決バージョンを保存してください。候補版で環境を複雑にすると、再現条件が消えます。

なお、node-pty上流では、パッケージの配置やElectron環境に依存した起動失敗の報告も公開されています。これはrc.7の不具合を意味しませんが、単純なBash入力が成功しても、配布形態やネイティブモジュールの読み込みまで合格したとは限らないことを示します。関連する事例はnode-ptyの公式Issueで確認できます。

リモートMacでは、ブラウザーの切断と処理の終了を同じ事象として扱わないでください。通信が切れた後もPTY上のプロセスが動いている可能性がありますが、再接続して制御を取り戻せる保証はありません。

次の手順で切り分けます。

• [ ] 切断前に実行コマンドと開始時刻を保存する
• [ ] 別の管理経路で対象プロセスの存在を確認する
• [ ] 再接続後、最後に見えた出力と新しい出力を比較する
• [ ] 入力を一つ送り、制御が戻っているか確認する
• [ ] 終了コード、生成物、ログファイルをMac側で確認する
• [ ] 途中で再実行して二重処理になっていないか確認する

画面が戻っただけでは復旧成功にしません。プロセスが停止しているのに表示だけが残る場合や、処理は継続しているのに入力制御だけ戻らない場合があります。バックグラウンド処理の受け入れ判定は、DeepSeek Harnessのバックグラウンドタスク検証のように、画面以外の終了条件も含めて設計してください。

比較では「動いた」「動かなかった」だけでなく、どの層が変わったかを記録します。

• Bashの起動自体が改善したか
• 出力の連続性だけが改善したか
• 取消後の子プロセスが変わったか
• 再接続後の表示だけが変わったか
• 同じMacで結果が再現するか

node-ptyの更新は、PTYの生成や入出力、端末サイズなどに関係する層へ影響します。一方、モデルの待機時間、Web UIの状態管理、接続経路、権限設定まで自動的に修正するものではありません。node-pty上流の変更履歴を読んだうえで、DeepSeek Harnessが実際に呼び出している機能だけを比較してください。

rc.7はリリース候補版です。底層依存が更新されたという理由だけで、購入判断や全面的な環境拡張へ進むべきではありません。候補版の互換性に差分がある可能性を残し、確認できたシナリオだけを試験対象へ加えてください。

• [ ] DeepSeek Harnessとnode-ptyの実バージョンを保存した
• [ ] Bashの入力反映と終了コードを確認した
• [ ] 長い出力で画面、プロセス、モデル待機を分離した
• [ ] 取消後に子プロセスが終了したことを確認した
• [ ] 実際に使う対話型プログラムを一つ選んだ
• [ ] 切断後の出力、入力制御、生成物を別々に確認した
• [ ] 旧版とrc.7を同じMac、同じコマンドで比較した
• [ ] 継続、制限、回退の条件を事前に決めた

遠隔環境の引き渡し直後に同じ項目を確認する場合は、利用するMac環境の引き渡し条件に、今回の再テスト項目をそのまま追加してください。必要な接続方式や作業条件を整理する際は、CALMVPSの環境確認ページも参照できます。端末の動作だけでなく、権限、作業ディレクトリ、接続経路が一致しているかを確認します。

必要な期間だけ検証用のリモートMacを用意する場合は、導入前に実行コマンド、必要な権限、再接続時の確認方法を整理してください。利用条件が曖昧なまま環境を替えると、rc.7の差分と環境差分を切り分けられません。短期検証では、同じ作業票を使って引き渡し時と回退時の状態を比較する方法が適しています。

検証用Macの接続条件を決める場合は、必要なシェル、権限、作業ディレクトリ、接続経路を先に明文化してください。商用環境の導入や試験範囲の拡大を先に決めるのではなく、同じ条件でrc.7と旧版を比較できる状態を作ることを優先します。詳しい環境確認項目はMac環境の利用条件でも確認できます。

node-ptyの更新は、端末互換性を改善するための重要な変更です。しかし、Bashの遅延修正と、長時間ビルド、切断後の復旧、取消処理の安定性は別々に検証する必要があります。v0.1.0-rc.7を使うなら、まず代表タスクで比較し、再現可能な証拠が揃った範囲だけを広げてください。

自前のMacや既存の仮想環境で続ける場合、端末セッションの保持、接続経路の切り分け、子プロセスの確認、環境差分の固定を毎回管理する負担が残ります。特に一時的な検証や複数のMac条件を比べる段階では、環境準備と回退作業がボトルネックになりがちです。

今回の判断では、node-pty更新を理由に全面移行するのではなく、入力、出力、取消、再接続の証拠を揃えたうえで、継続、制限付き、回退のいずれかへ進んでください。