Cinq scénarios réels pour lesquels CPYNET est réellement conçu - pas hypothétiques. Chaque commande ci-dessous est une entrée réelle contre un déploiement réel, montrée avec la sortie exacte qu'elle produit.
Vous êtes connecté en SSH à un serveur distant, quelque chose a échoué, et vous devez faire parvenir les lignes de log pertinentes à un coéquipier tout de suite - sans un autre round d'accès SSH ni envoyer un fichier par e-mail.
$ journalctl -u myservice -n 200 | cpy482913curl "https://llmtag.com/482913"
Deux lignes en retour : le code nu et une commande curl prête à l'emploi. Collez l'une ou l'autre dans le chat - quiconque la lit obtient le texte exact, et il disparaît dès qu'il le fait :
$ 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
C'est la fonction shell pst - elle dépose aussi le texte dans son presse-papiers en effet secondaire, pure commodité. Pas de cpy/pst installé de l'autre côté ? La ligne simple curl "https://llmtag.com/482913" que cpy a affichée ci-dessus fonctionne exactement pareil, aucun alias requis. Dans tous les cas, une seconde lecture du même code (par n'importe qui, vous y compris) renvoie une erreur 404 - il a déjà disparu.
Certains environnements - ordinateurs portables d'entreprise verrouillés, sessions VDI, bureaux distants sans presse-papiers partagé entre l'hôte et l'invité - ne vous laissent tout simplement pas copier de texte via le presse-papiers du système d'exploitation.
$ echo "mot de passe wifi : correcthorsebatterystaple" | cpy174205curl "https://llmtag.com/174205"
$ pst 174205mot de passe wifi : correcthorsebatterystaple
CPYNET ne touche de toute façon jamais le presse-papiers du système sur la machine verrouillée - tout ressort en texte brut via curl, donc un presse-papiers désactivé n'a pas d'importance là-bas. La machine qui le relit est une machine normale, donc le confort du presse-papiers de pst fonctionne bien de ce côté. Pas de terminal sous la main côté réception ? Scannez plutôt le code QR affiché après l'envoi avec votre téléphone - il s'ouvre directement dans le navigateur.
Tout le monde avec qui vous devez partager ne veut pas exécuter une commande - un client, un manager, ou un coéquipier sur une machine verrouillée a juste besoin d'un lien et d'un mot de passe qu'il tape une fois, dans un navigateur.
$ echo "staging: https://staging.internal utilisateur: demo mot de passe: xQ9!vB2m" | cpy -password=handoff2026591042curl "https://llmtag.com/591042"
Envoyez le lien complet (pas seulement le code - le code seul a quand même besoin de la bonne URL) et le mot de passe par des canaux séparés. Ils ouvrent le lien dans n'importe quel navigateur, tapent le mot de passe dans le champ de la page, et le lisent une fois - pas de CLI, pas d'extension navigateur, pas de compte. Un mauvais mot de passe échoue sans consommer la lecture ; un mot de passe manquant redemande simplement.
Un conteneur sans volume partagé, une étape de build isolée, la sortie intermédiaire d'un job CI - partout où stdout est accessible mais où le système de fichiers n'est pas partagé avec l'endroit où vous avez réellement besoin du résultat.
$ docker run myimage some-command | curl --data-binary @- https://llmtag.com/https://llmtag.com/718234
Un pipe brut (pas de cpy installé dans le conteneur) ne récupère que l'URL nue - toujours exactement une ligne, toujours pipeable vers l'étape suivante :
$ pst 718234{"status":"ok","records_processed":48213}
Le conteneur n'avait pas cpy installé, donc il est retombé sur un pipe brut - votre propre machine l'a presque certainement, donc le relire consiste juste en pst (un simple curl "https://llmtag.com/718234" fonctionne pareil sinon). Fonctionne de la même façon avec kubectl exec, une image minimale scratch/distroless qui n'a même pas curl (voir le repli netcat), ou tout autre environnement où la seule chose que vous pouvez atteindre de façon fiable est un pipe.
Le mot de passe ci-dessus (-password=) est vérifié côté serveur - le serveur voit brièvement le texte en clair pour le vérifier. cpy -e est une couche différente, plus forte : le chiffrement se produit entièrement sur votre machine avant que quoi que ce soit ne soit envoyé, et le serveur ne stocke jamais que du texte chiffré.
$ echo "phrase secrète ssh root : Tr0ub4dor&3" | cpy -e305817curl "https://llmtag.com/305817"key (share separately, never with the link/code): n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdE
Envoyez le code par un canal et la clé par un autre (un appel, un second fil de discussion, en personne) - quiconque n'a que le lien ou le code récupère du texte chiffré illisible, serveur inclus.
$ pst 305817 -key=n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdEphrase secrète ssh root : Tr0ub4dor&3
Omettez -key= et pst affiche le texte chiffré brut à la place - le serveur n'a de toute façon jamais assez d'informations pour le déchiffrer, avec ou sans clé.