Codex Cloud, avec n'importe quel agent IA

OpenAI a lancé Codex Cloud : on décrit une tâche, Codex la traite sur une machine à lui pendant que votre ordinateur dort, et on revient relire une pull request. L'idée est bonne. Elle est aussi attachée à un agent (Codex), à un compte (ChatGPT) et à un hébergeur de code (GitHub).

Les briques, elles, sont simples : une machine neuve par tâche, un environnement prêt, des secrets bien rangés, un résultat qu'on relit. Cet article les assemble avec n'importe quel agent en ligne de commande et n'importe quel modèle, sur une machine FFxF louée à l'heure à Montréal. Deux voies : votre agent délègue lui-même par MCP, ou un script de cinquante lignes lance la tâche sans vous.

1. Ce que fait Codex Cloud

D'après sa documentation, Codex Cloud repose sur cinq idées :

• Un environnement publié : les dépôts, les dépendances et les outils, préparés une fois, avec un script d'installation.
• Un espace isolé par tâche, tiré de cet environnement : deux tâches ne se marchent pas dessus.
• Le travail continue sans vous : l'ordinateur peut dormir.
• Des secrets réseau : un mandataire substitue la vraie valeur pour les domaines autorisés, le processus ne voit qu'un substitut.
• La revue : on lit les changements, on demande une reprise, on ouvre la PR.

2. Les mêmes briques, en pièces détachées

Aucune de ces idées n'a besoin d'un produit fermé. Voici l'équivalent de chacune avec une machine FFxF.

• Environnement publié → l'image coding-agent (Ubuntu, Docker, git, gh, Node.js, Python et uv, Claude Code, Codex CLI) plus un .agent/setup.sh dans le dépôt.
• Espace isolé par tâche → une VM KVM par tâche, avec root et Docker, détruite à la fin.
• Continue sans vous → la machine tourne à Montréal ; la tâche part d'un script, d'une CI ou de votre agent.
• Secrets réseau → des clés à portée réduite, envoyées par l'entrée standard, effacées avec la machine.
• Revue et PR → une branche poussée et une PR en brouillon, ouverte par gh.
• L'agent, Codex → Codex, Claude Code, ou tout agent qui s'installe en ligne de commande.

Une Nano (1 vCPU, 2 Go) coûte 0,018 CAD de l'heure, et une machine créée puis détruite dans l'heure coûte exactement cela. Pour une compilation lourde, prenez une offre plus grande : les prix sont dans Forfaits et régions.

3. Première voie : votre agent délègue

Si vous travaillez déjà avec un agent sur votre poste, le plus court est de lui donner les outils pour louer sa propre machine. Le serveur MCP de FFxF (https://ffxf.net/mcp) s'installe dans Claude Code, Codex, Cursor et les autres clients MCP ; la phrase suivante suffit pour qu'il s'installe seul :

Installe le serveur MCP de FFxF en suivant https://ffxf.net/agents.md. Ma clé API est dans la variable d'environnement FFXF_API_KEY.

Ajoutez ensuite au AGENTS.md ou au CLAUDE.md du projet le bloc de Mode distant : quand une tâche demande une vraie machine, l'agent en estime le prix, la commande, y travaille en SSH et la détruit. La démo appel par appel montre une exécution réelle : livrée en 42 secondes, détruite en 10, 0,018 CAD.

Cette voie garde un humain dans la boucle, mais elle suppose une session ouverte. Pour confier une tâche et fermer le portable, il faut la deuxième.

4. Deuxième voie : une tâche, une machine, une PR

Le script ci-dessous fait ce que fait Codex Cloud pour une tâche : il commande une machine, y clone le dépôt, lance l'agent sans surveillance, pousse une branche, ouvre une PR en brouillon, et détruit la machine, qu'il ait réussi ou non.

Il lui faut, dans l'environnement :

• FFXF_API_KEY : une clé FFxF limitée à vms.read, vms.create et vms.destroy, créée dans Compte → Clés d'API.
• GH_TOKEN : un jeton GitHub à granularité fine, limité au dépôt, avec les droits Contents et Pull requests en écriture.
• ANTHROPIC_API_KEY ou OPENAI_API_KEY, selon l'agent.
• Votre clé publique ~/.ssh/id_ed25519.pub, déjà ajoutée au compte FFxF.

#!/usr/bin/env bash
# ffxf-task : une tâche d'agent sur une machine neuve, rendue en PR, puis la machine est détruite.
# Usage : ffxf-task propriétaire/dépôt "la tâche" [claude|codex]
set -euo pipefail
REPO=$1 TACHE=$2 AGENT=${3:-claude}
API=https://api.ffxf.net/v1
AUTH="Authorization: Bearer $FFXF_API_KEY"
NOM="task-$(date +%s)"
CLE=$(ssh-keygen -lf ~/.ssh/id_ed25519.pub | awk '{print $2}')

# 1. Commander : Nano, image coding-agent, à l'heure, clé SSH seulement.
CORPS=$(jq -n --arg h "$NOM" --arg k "$CLE" '{plan: "nano", region: "montreal",
  image: "coding-agent", hostname: $h, billing: "hourly",
  password_delivery: "none", ssh_keys: [$k]}')
VM=$(curl -sf "$API/vms" -H "$AUTH" -H "Content-Type: application/json" \
     -H "Idempotency-Key: $NOM" -d "$CORPS" | jq -r .data.vm.id)

# Quoi qu'il arrive ensuite, la machine est détruite à la sortie du script.
trap 'curl -sf -X DELETE "$API/vms/$VM?confirm=$NOM" -H "$AUTH" >/dev/null && echo "$NOM détruite"' EXIT

# 2. Attendre la livraison, puis SSH.
until [ "$(curl -sf "$API/vms/$VM" -H "$AUTH" | jq -r .data.status)" = running ]; do sleep 5; done
IP=$(curl -sf "$API/vms/$VM" -H "$AUTH" | jq -r .data.ipv4)
SSH=(ssh -o StrictHostKeyChecking=accept-new "ubuntu@$IP")
until "${SSH[@]}" true 2>/dev/null; do sleep 3; done

# 3. Les secrets passent par l'entrée standard : ni ligne de commande, ni historique.
"${SSH[@]}" 'umask 077; cat > ~/.agent.env' <<EOF
GH_TOKEN=$GH_TOKEN
ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY:-}
OPENAI_API_KEY=${OPENAI_API_KEY:-}
EOF

# 4. Le travail, sur la machine.
"${SSH[@]}" "bash -s -- $(printf '%q ' "$REPO" "$NOM" "$AGENT" "$TACHE")" <<'EOF'
set -euo pipefail
set -a; . ~/.agent.env; set +a
gh auth setup-git
git config --global user.name "Agent FFxF"
git config --global user.email "agent@users.noreply.github.com"
gh repo clone "$1" ~/work/repo && cd ~/work/repo
git switch -c "agent/$2"
[ -x .agent/setup.sh ] && .agent/setup.sh
case "$3" in
  claude) claude -p "$4" --dangerously-skip-permissions ;;
  codex)  printenv OPENAI_API_KEY | codex login --with-api-key >/dev/null
          codex exec --dangerously-bypass-approvals-and-sandbox "$4" ;;
esac
git add -A
git diff --cached --quiet && { echo "Aucun changement."; exit 0; }
git commit -qm "$4"
git push -qu origin HEAD
gh pr create --draft --fill
EOF

On le lance ainsi, et on peut en lancer plusieurs à la fois :

chmod +x ffxf-task
./ffxf-task mon-org/mon-depot "Le test test_facture_arrondi échoue : trouve la cause et corrige-la" &
./ffxf-task mon-org/mon-depot "Ajoute la pagination à GET /clients, avec les tests" codex &
wait

Chaque appel prend sa propre machine, comme chaque tâche Codex Cloud prend son propre espace. Le quota par défaut est de cinq machines par compte.

5. Ce qui compte dans ce script

• Le trap est posé dès que la machine existe. Échec de l'agent, coupure SSH, Ctrl+C : la machine est détruite à la sortie du script. Une machine oubliée est la seule vraie source de dépense.
• La clé FFxF ne quitte pas votre poste. La machine reçoit un jeton GitHub limité à un dépôt et la clé du modèle, rien qui lui permette de commander ou de détruire quoi que ce soit.
• Les secrets passent par l'entrée standard, dans un fichier en 600 : ils n'apparaissent ni dans la liste des processus ni dans un historique, et disparaissent avec le disque. Codex Cloud fait mieux sur ce point (le processus ne voit jamais la vraie valeur) ; ici, plafonnez la dépense chez le fournisseur du modèle.
• --dangerously-skip-permissions et son équivalent Codex sont raisonnables ici, et seulement ici : la machine est jetable, n'a accès à rien d'autre, et sera effacée dans l'heure.
• .agent/setup.sh, s'il existe dans le dépôt, joue le rôle du script d'installation de Codex Cloud : dépendances, base de données de test, variables. L'agent lit aussi l'AGENTS.md ou le CLAUDE.md du dépôt, comme en local.
• La clé d'idempotence : si la commande est renvoyée après une coupure réseau, l'API rend la première réponse au lieu de créer une seconde machine.

Une différence reste : Codex Cloud garde l'environnement prêt entre deux tâches, alors qu'ici chaque tâche repart d'une image propre et réinstalle ses dépendances. Pour un projet Node ou Python courant, c'est une minute ; pour un projet qui en demande dix, gardez une machine au mois comme poste de travail de l'agent et lancez les tâches dessus.

6. N'importe quel agent, n'importe quel modèle

Le case du script est le seul endroit qui dépend de l'agent. Quelques variantes :

• Claude Code avec un abonnement plutôt qu'une clé API : claude setup-token sur votre poste donne un jeton longue durée, à écrire en CLAUDE_CODE_OAUTH_TOKEN dans ~/.agent.env à la place d'ANTHROPIC_API_KEY.
• Codex avec un modèle ouvert : codex exec --oss --local-provider ollama utilise un serveur Ollama plutôt que l'API d'OpenAI ; son adresse se règle dans la configuration de Codex.
• Un autre agent : installez-le dans .agent/setup.sh et ajoutez une ligne au case. Il lui faut un mode non interactif (une consigne en argument, un code de sortie) ; la plupart en ont un.
• Votre propre modèle : une Nano ne fait pas tourner un LLM. Hébergez-le sur une machine plus grande qui reste allumée (voir Héberger Hermes et Ollama), et faites pointer les agents jetables vers elle. Le code et le modèle restent alors au Canada.

7. Lancer une tâche depuis une issue GitHub

Codex Cloud se déclenche depuis ChatGPT, le téléphone ou Slack. Le script, lui, se déclenche de partout où une commande peut tourner : un cron pour une tâche de nuit, ou GitHub Actions quand on pose l'étiquette agent sur une issue, le script étant versionné dans tools/ffxf-task.

# .github/workflows/agent.yml
name: agent
on:
  issues:
    types: [labeled]
jobs:
  tache:
    if: github.event.label.name == 'agent'
    runs-on: ubuntu-latest
    timeout-minutes: 120
    steps:
      - uses: actions/checkout@v4
      - name: Clé SSH
        env:
          CLE_SSH: ${{ secrets.FFXF_SSH_KEY }}
        run: |
          install -d -m 700 ~/.ssh
          printf '%s\n' "$CLE_SSH" > ~/.ssh/id_ed25519 && chmod 600 ~/.ssh/id_ed25519
          ssh-keygen -y -f ~/.ssh/id_ed25519 > ~/.ssh/id_ed25519.pub
      - name: Tâche
        env:
          FFXF_API_KEY: ${{ secrets.FFXF_API_KEY }}
          GH_TOKEN: ${{ secrets.AGENT_GH_TOKEN }}
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          NUMERO: ${{ github.event.issue.number }}
        run: ./tools/ffxf-task "$GITHUB_REPOSITORY" "Traite l'issue #$NUMERO (gh issue view $NUMERO) et ouvre une PR."

Deux précautions. Le texte de l'issue n'entre jamais dans la commande : seul son numéro passe, et l'agent lit l'issue lui-même avec gh issue view. Et seuls les membres du dépôt peuvent poser une étiquette, mais le texte de l'issue vient de quiconque l'a écrite : c'est une consigne comme une autre pour l'agent, d'où le jeton limité à ce seul dépôt et la PR en brouillon, relue avant fusion.

Si le runner est tué sans préavis, le trap n'a pas le temps de s'exécuter. Le budget mensuel de la console borne la dépense, et le relevé GET /v1/usage?group_by=vm des Recettes montre toute machine task-… qui aurait survécu.

8. Ce que chacun fait mieux

Codex Cloud n'a rien à monter : l'environnement se prépare en conversation, la revue se fait dans l'application, sur le téléphone aussi, et ses secrets réseau sont plus étanches qu'un fichier sur la machine. Si vous êtes déjà sur ChatGPT, Codex et GitHub, c'est le chemin le plus court.

L'assemblage FFxF vaut mieux quand vous tenez à choisir :

• l'agent et le modèle, y compris un modèle que vous hébergez ;
• une vraie VM : root, Docker, une IPv4 et une IPv6 publiques, un service qui reste joignable le temps de le tester ;
• une facture à l'heure, sur un crédit prépayé, avec un budget mensuel qui arrête les machines au-delà de 120 % ;
• l'endroit où tourne le code : Montréal, au Canada ;
• le déclencheur : un script, un cron, n'importe quelle CI, n'importe quel hébergeur de code.

L'API complète est documentée dans la documentation, et les scripts de base dans Recettes.