Пять реальных сценариев, для которых CPYNET на самом деле создан - не гипотетических. Каждая команда ниже - это реальный ввод на реальном развёртывании, показанный с точным результатом, который она даёт.
Вы подключены по SSH к удалённому серверу, что-то сломалось, и вам нужно прямо сейчас передать релевантные строки лога коллеге по команде - без ещё одного раунда SSH-доступа или отправки файла по почте.
$ journalctl -u myservice -n 200 | cpy482913curl "https://llmtag.com/482913"
Две строки в ответ: голый код и готовая к запуску команда 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
Это shell-функция pst - она также попутно кладёт текст в буфер обмена, чистое удобство. Нет cpy/pst на другой стороне? Простая строка curl "https://llmtag.com/482913", которую вывел cpy выше, работает точно так же, без алиаса. В любом случае повторное чтение того же кода (кем угодно, включая вас) вернёт 404 - его уже нет.
Некоторые окружения - заблокированные корпоративные ноутбуки, VDI-сессии, удалённые рабочие столы без общего буфера обмена между хостом и гостем - просто не дают скопировать текст через системный буфер обмена вообще.
$ echo "пароль от wifi: correcthorsebatterystaple" | cpy174205curl "https://llmtag.com/174205"
$ pst 174205пароль от wifi: correcthorsebatterystaple
CPYNET в любом случае никогда не трогает системный буфер обмена на заблокированной машине - всё выходит как обычный текст через 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
Обычный pipe (без cpy в контейнере) возвращает только голый URL - всё ещё ровно одна строка, всё ещё можно передать по pipe на следующий шаг:
$ pst 718234{"status":"ok","records_processed":48213}
В контейнере не было установлено cpy, поэтому он использовал обычный pipe - на вашей собственной машине он почти наверняка есть, так что прочитать обратно - это просто pst (обычный curl "https://llmtag.com/718234" работает так же, если его нет). Работает так же с kubectl exec, минимальным scratch/distroless-образом, в котором даже curl нет (см. запасной вариант через netcat), или любым другим окружением, где единственное, до чего можно надёжно дотянуться - это pipe.
Пароль выше (-password=) проверяется на сервере - сервер кратко видит открытый текст, чтобы его проверить. cpy -e - это другой, более сильный слой: шифрование происходит полностью на вашей машине до отправки чего-либо, и сервер всегда хранит только шифротекст.
$ echo "root ssh пароль-фраза: Tr0ub4dor&3" | cpy -e305817curl "https://llmtag.com/305817"key (share separately, never with the link/code): n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdE
Отправьте код по одному каналу, а ключ - по другому (звонок, вторая переписка, лично) - у кого есть только ссылка или код, получит нечитаемый шифротекст, включая сервер.
$ pst 305817 -key=n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdEroot ssh пароль-фраза: Tr0ub4dor&3
Опустите -key=, и pst выведет вместо этого сырой шифротекст - у сервера в любом случае никогда не хватает информации, чтобы его расшифровать, с ключом или без.