ctx-wire - Coding agent 向けの command output compressor

Coding agent に test、lint、build を実行させるとき、context を一番消費するのは error そのものではなく、大量の繰り返し log であることが多いです。npm test、go test ./...、monorepo build は数千行の output を出しますが、model が本当に必要とするのは failure summary、関連する stack trace、exit code、少しの周辺 context だけです。

今日紹介する pivanov/ctx-wire は、この問題に向けた tool です。Go 製の local CLI で、user の command を実行し、YAML で宣言した filters によって stdout/stderr を圧縮し、sensitive fragment を redact します。そのうえで短い結果を agent に渡し、full log は disk に保存します。

公開時点の GitHub search result では、約 46 stars、0 forks。主な言語は Go、license は MIT です。Project は 2026-06-05 に作成され、現在も更新されています。Release page の latest version は v0.1.22、公開日は 2026-06-13 です。

プロジェクト概要

項目	内容
Repository	pivanov/ctx-wire
位置づけ	Coding agent 向けの command output compression / redaction CLI
Stars	約 46
Forks	0
主な言語	Go
License	MIT
Latest release	v0.1.22

解くのは「log が多すぎる」問題

多くの agent tool は shell command を実行できます。ただし、その後の output handling は粗くなりがちです。全部を context に入れるか、先頭や末尾だけを切り出すか、どちらかになりやすい。前者は token を浪費し、後者は本当の failure clue を落とすことがあります。

ctx-wire の考え方は「agent に短い report を渡す」ことに近いです。通常実行する command を次のように wrap します。

ctx-wire run -- npm test

Command は通常どおり実行され、exit code も保持されます。違うのは、raw output が local run directory に保存され、設定に従って model に見せるべき部分だけが抽出されることです。Agent は圧縮された summary を読み、人間が必要なら full log を開けます。

これは単純な truncation より安定します。Build log の noise は最初に出ることもあり、failure reason は中間や末尾に埋まることもあります。固定行数だけを残すと重要な手がかりを失いやすい。ctx-wire は filter pipeline によって、「どの行を残すか、どの行を落とすか、どの文字列を置換するか」を明示できます。

Filter pipeline が中心

README と FILTERS.md にある filter は、いくつかの実務的な needs をカバーしています。Regex で content を include / exclude する、head / tail を取る、error window を抽出する、重複行を圧縮する、JSON を扱う、token や character budget を制限する、secret を redact する、といった用途です。

この model の強みは declarative であることです。各 project が一時的な script で log を掃除する代わりに、「test failure では何を残すか」を config に書けます。Team は command ごとに profile を用意できます。

1. Unit test では failed test name、assertion、stack trace、summary を残す。
2. TypeScript compile では diagnostic、file path、error code を残す。
3. Docker build では failed step 周辺の window を残す。
4. Long-running script では末尾 summary と warning/error を残す。

この設定が安定すれば、人間にも agent にも再利用できます。AI coding workflow では、毎回 prompt で「関係ない log を無視して」と頼むより、tool が同じ形の output を出す方が信頼しやすいです。

Redaction を default workflow に入れる

Coding agent が command output を読むとき、log には token、URL、environment variable、cookie、database connection string、cloud service key が混じる可能性があります。Model が能動的に外へ送らないとしても、最小露出の観点では、agent に渡す前に filter するべきです。

ctx-wire は redaction を filter chain に入れています。Documentation でも secret scrubbing は core capability として扱われています。これは「log を model に見せたいが、そのまま渡したくない」場面に向いています。たとえば CI failure log に signed URL が入る、test framework が .env を誤って出す、SDK が debug mode で auth header を出す、といった case です。

もちろん、これでどんな sensitive output でも安全になるわけではありません。より堅い運用は、upstream command が secret を出さないようにし、ctx-wire を第二防衛線として使い、config に team が気にする pattern を明示することです。

Full log は local に残し、短い結果だけ agent へ

ctx-wire の境界は実用的です。これは logging platform ではなく、test report system の代替でもありません。Local で一度実行した command の input/output を整理するための small tool です。

Full log が disk に残る点は重要です。Agent は compressed summary を読んで修正案を出せますが、その方向が違う場合、人間は raw stdout/stderr を確認する必要があります。Raw log を残すことで、「summary が短すぎてあとから復元できない」問題を避けられます。

この layering は collaboration にも向いています。Agent には短い output を渡して先に問題を切り分けさせる。人間の review が必要になったら、local run directory の full log と見比べる。時間のかかる command を再実行しなくても、同じ事実を確認できます。

Config file で project habit にする

CONFIG.md によると、ctx-wire は YAML config を使います。Command、filters、budget、output directory などを reusable profile として定義できます。日常開発では、長い CLI arguments を覚えるより、これが大きな価値になります。

Project では、よく使う command をいくつかの入口にできます。

ctx-wire run test
ctx-wire run lint
ctx-wire run build

それぞれの入口の後ろに別々の filters を置きます。Test command は failure context、lint command は file と rule name、build command は failed phase と error window を重視する。Agent は同じ stable interface を呼ぶだけでよく、各 tool の output format を毎回理解しなくて済みます。

これは prompt の説明量も減らします。AGENTS.md に「test 後は failure 部分だけコピーする」と書くより、command 自体が model-readable output を生成する方が安定します。人間向けの規約は忘れられますが、tool boundary は保ちやすいです。

Local agent workspace に合う

ctx-wire は大きな platform component というより、local AI coding workspace に置くのが合っています。強みは軽さです。任意の command を wrap し、stdout/stderr を処理し、結果を caller に返す。

先に試す価値があるのは、次のような状況です。

1. Agent が長い test log で context を使い切りがち。
2. Monorepo build の failure が大量の warning の後ろに埋もれる。
3. Team が command output を AI tool に渡す前に redact したい。
4. Full log は残したいが、model には短い summary だけ渡したい。
5. AGENTS.md、Makefile、task runner で固定 command entrypoint をすでに持っている。

一方で、project の command output がもともと短い場合や、成熟した CI artifact / test report parser がすでにある場合、ctx-wire の効果は大きくないかもしれません。これは「local agent が command を実行するときの output gate」として見るのが自然です。

普通の log truncation との違い

普通の truncation は長さを減らします。ctx-wire が狙うのは information density です。Command output を次の 3 層に分けます。

1. Raw log: 完全に保存し、人間や後続 tool が復元できる。
2. Filtered result: Project config に従って high-value fragment を抽出する。
3. Agent context: Budget を制御し、model に渡す短い text にする。

この 3 層を分けると、engineering 上の判断が明確になります。「全部 model に貼る」か「最後の 100 行だけ貼る」かを毎回選ばなくてよくなります。Sensitive information の manual cleanup も減らせます。設定済み pipeline は、安定して同じ形の report を出せます。

Multi-agent workflow では特に重要です。複数の agent が同じ format の failure summary を読めば、handoff のたびに log の範囲が変わって context が欠けることを避けやすくなります。

まとめ

pivanov/ctx-wire は派手な agent framework ではありません。狭く、engineering 寄りの command-line tool です。Command を実行し、full log を保存し、output を圧縮し、sensitive content を redact し、短い結果を coding agent に渡します。

Codex、Claude Code、OpenCode、その他の CLI agent を real project に接続しているなら、いずれ「command output が長すぎる、乱雑すぎる、しかも sensitive data が混じる」問題に当たります。ctx-wire の価値はそこにあります。Command output を model context に入れる前に、auditable で configurable な整理層を挟めることです。

この方向は small team が試しやすいです。既存の test tool や build tool を置き換える必要はありません。Command と agent の間に clear wire を足すだけです。Full facts は local に残し、高密度な summary だけを model に渡せます。