ユースケース

CPYNETが実際に作られた5つの現実的なシナリオです - 仮説ではありません。以下の各コマンドは、実際のデプロイに対する実際の入力であり、実際に生成される出力とともに示されています。

SSHセッションからログを共有する

リモートサーバーにSSH接続していて、何かが失敗し、今すぐ関連するログ行をチームメイトに届ける必要がある - 追加のSSHアクセスやファイルのメール送信なしで。

あなた、サーバー上で

$ journalctl -u myservice -n 200 | cpy482913curl "https://llmtag.com/482913"

2行返ってきます：素のコードと、すぐ実行できるcurlコマンドです。どちらかをチャットに貼り付ければ - 読んだ人は正確なテキストを受け取り、読んだ瞬間に消えます：

あなたのチームメイト

$ pst 482913Aug 08 14:02:11 myservice[1823]: connection refused: db.internal:5432Aug 08 14:02:11 myservice[1823]: retrying in 5s...Aug 08 14:02:16 myservice[1823]: connection refused: db.internal:5432

これがpstシェル関数です - 副次効果としてテキストをクリップボードにも置いてくれる、純粋な利便性です。相手側にcpy/pstがインストールされていない場合は？上でcpyが出力した単純なcurl "https://llmtag.com/482913"の行がまったく同じように動作し、エイリアスは不要です。いずれにせよ、同じコードを2回目に読もうとすると（あなたを含め誰であっても）404が返ります - すでに消えています。

クリップボードが無効化されたマシンからテキストを移動する

一部の環境 - ロックダウンされた企業のノートPC、VDIセッション、ホストとゲスト間でクリップボードが共有されないリモートデスクトップ - では、そもそもOSのクリップボード経由でテキストをコピーして持ち出すことができません。

ロックダウンされたマシン

$ echo "wifiパスワード: correcthorsebatterystaple" | cpy174205curl "https://llmtag.com/174205"

自分のマシン、数分後

$ pst 174205wifiパスワード: correcthorsebatterystaple

CPYNETはロックダウンされたマシン上でOSのクリップボードにいずれにせよ一切触れません - すべてはcurl経由でプレーンテキストとして出て行くので、クリップボードが無効でもそこでは関係ありません。読み戻す側のマシンは通常のマシンなので、pstのクリップボードの利便性はそちら側では問題なく機能します。受信側に手元にターミナルがない場合は？送信後に表示されるQRコードをスマートフォンでスキャンしてください - ブラウザで直接開きます。

パスワード保護されたリンクを技術に詳しくないチームメイトに渡す

共有相手全員がコマンドを実行したいわけではありません - クライアント、マネージャー、あるいはロックダウンされたマシン上のチームメイトには、ブラウザで一度入力するリンクとパスワードだけが必要です。

あなた

$ echo "staging: https://staging.internal  ユーザー: demo  パスワード: xQ9!vB2m" | cpy -password=handoff2026591042curl "https://llmtag.com/591042"

プレーンなリンク（コードだけでなく - コード単体でも正しいURLが必要です）とパスワードを別々のチャネルで送ってください。相手はどのブラウザでもリンクを開き、ページ上のフィールドにパスワードを入力し、一度だけ読み取ります - CLIもブラウザ拡張機能もアカウントも不要です。パスワードが間違っていても読み取り回数は消費されずに失敗し、未入力の場合は再度プロンプトが表示されるだけです。

コンテナの出力をホストに戻す

共有ボリュームのないコンテナ、独立したビルドステップ、CIジョブの中間出力 - stdoutにはアクセスできるが、ファイルシステムが実際に結果を必要とする場所と共有されていないあらゆる場所。

コンテナの内部

$ docker run myimage some-command | curl --data-binary @- https://llmtag.com/https://llmtag.com/718234

素のパイプ（コンテナ内にcpyがインストールされていない）では、素のURLだけが返ります - それでもちょうど1行で、次のステップにパイプ可能です：

ホスト上で

$ pst 718234{"status":"ok","records_processed":48213}

コンテナにはcpyがインストールされていなかったため、素のパイプにフォールバックしました - 自分のマシンにはほぼ確実にインストールされているので、読み戻すのは単にpstだけです（なければ単純なcurl "https://llmtag.com/718234"も同様に動作します）。kubectl execや、curlすら入っていない最小限のscratch/distrolessイメージ（netcatフォールバック参照）、あるいは確実に到達できるものがパイプだけの他の環境でも同じように動作します。

CLIからの共有をエンドツーエンドで暗号化する

上記のパスワード（-password=）はサーバー側で検証されます - サーバーは検証のために平文を一瞬だけ見ます。cpy -eは異なる、より強力な層です：暗号化は何かが送信される前に完全にあなたのマシン上で行われ、サーバーは常に暗号文しか保存しません。

あなた、クライアント側で暗号化中

$ echo "root sshパスフレーズ: Tr0ub4dor&3" | cpy -e305817curl "https://llmtag.com/305817"key (share separately, never with the link/code): n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdE

コードは1つのチャネルで、鍵は別のチャネルで送ってください（電話、別のチャットスレッド、対面など） - リンクやコードだけを持つ人は、サーバーを含め、読み取れない暗号文しか受け取れません。

コードと鍵の両方を持つ人

$ pst 305817 -key=n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdEroot sshパスフレーズ: Tr0ub4dor&3

-key=を省略すると、pstは代わりに生の暗号文を出力します - 鍵の有無にかかわらず、サーバーにはそれを復号するのに十分な情報がそもそもありません。