おそろしや。codexはバージョン0.142.0以降を使いましょう。
年640TB書き込みはSSD殺しすぎるだろ。知らぬ間に寿命が削られるのホント恐ろしいな
6月に既に直ってるものを7月に出すのもどうなんだ？日頃のトラブルシューティングでも最新版にしてんのか？再起動はしたのか？からのスタートだろ？
こんなの自分なら絶対気づかないわ。俺、そういう自信はあるんだ。
15%に減らしても大概な書き込み量やで。
元のissueを見る限りtraceレベルのロギングが未だ全て除去されておらずissueはopenなままで、最初の修正以降OpenAIは沈黙している
2TBのSSDを2年で潰す速度だ …SSD高い時期にこれは痛すぎ
こわすぎだろcodex
バイブコーディングでCodexを作ったからこういう人間ならしないミスが発生したケースと、人間が意思決定してこういう仕様にしたケースだったら、どっちも問題だな
実際にデバッグ作業等を依頼されたら網羅的に記録するのは原則通りだし、人間にとっては面倒なことでも機械任せなら出来る。その副作用のようなもので、trace全消ししたらデバッグ作業できなくなるのではなかろうか。
見たら100Mくらいだったのでまだ安心 使ってないので使わないままに……
恐ろしいのでsqliteのトリガーでログ書き込みしない設定しといた。実際にMacダメにした人もいるらしい
SQLiteログ用の出力設定がデフォルトで TRACE に
AI需要でSSDが爆売れしているだけでなく、AIがSSDを壊し更に爆売れしてキオクシアが儲かる構図だ
『エージェント型ツールは「あとで挙動を再現・分析できるように」と観測ログを厚く取りたがるが、その保存先が開発者の物理ドライブになった瞬間、詳細度の既定値は寿命コストに直結する。』
Codex CLIのSQLiteログが約21日で37TB、年換算640TBをSSDに書き込み。TRACE既定が原因で、修正PRによりログ量は約85%削減。0.142.0以降の確認推奨。
Codexが年640TBをSSDに書いていた、原因のTRACEログを追う
おそろしや。codexはバージョン0.142.0以降を使いましょう。
年640TB書き込みはSSD殺しすぎるだろ。知らぬ間に寿命が削られるのホント恐ろしいな
6月に既に直ってるものを7月に出すのもどうなんだ？日頃のトラブルシューティングでも最新版にしてんのか？再起動はしたのか？からのスタートだろ？
こんなの自分なら絶対気づかないわ。俺、そういう自信はあるんだ。
15%に減らしても大概な書き込み量やで。
元のissueを見る限りtraceレベルのロギングが未だ全て除去されておらずissueはopenなままで、最初の修正以降OpenAIは沈黙している
2TBのSSDを2年で潰す速度だ …SSD高い時期にこれは痛すぎ
こわすぎだろcodex
バイブコーディングでCodexを作ったからこういう人間ならしないミスが発生したケースと、人間が意思決定してこういう仕様にしたケースだったら、どっちも問題だな
実際にデバッグ作業等を依頼されたら網羅的に記録するのは原則通りだし、人間にとっては面倒なことでも機械任せなら出来る。その副作用のようなもので、trace全消ししたらデバッグ作業できなくなるのではなかろうか。
見たら100Mくらいだったのでまだ安心 使ってないので使わないままに……
恐ろしいのでsqliteのトリガーでログ書き込みしない設定しといた。実際にMacダメにした人もいるらしい
SQLiteログ用の出力設定がデフォルトで TRACE に
AI需要でSSDが爆売れしているだけでなく、AIがSSDを壊し更に爆売れしてキオクシアが儲かる構図だ
『エージェント型ツールは「あとで挙動を再現・分析できるように」と観測ログを厚く取りたがるが、その保存先が開発者の物理ドライブになった瞬間、詳細度の既定値は寿命コストに直結する。』
Codex CLIのSQLiteログが約21日で37TB、年換算640TBをSSDに書き込み。TRACE既定が原因で、修正PRによりログ量は約85%削減。0.142.0以降の確認推奨。