probleme avec web ui

[cloud mica]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[pearl citrus]

Tu peux donner un peu plus de contexte ? Première info utile :

openclaw --version

À ma lecture du code/docs, le Web/Control UI sert bien les médias assistant via une route authentifiée, surtout images/audio générés, mais il ne transforme pas forcément n’importe quel fichier local créé par l’agent en “lien public téléchargeable” comme une pièce jointe Discord. Pour un PDF/CSV/zip/etc., le workaround le plus fiable est de demander à l’agent de sauvegarder le fichier dans le workspace et de te donner le chemin local exact, ou d’utiliser un canal qui supporte les pièces jointes.

Si tu t’attendais à un bouton/lien de téléchargement dans le Web UI pour les fichiers non-image, ça ressemble plutôt à une limite/bug à ouvrir ici : https://github.com/openclaw/openclaw/issues

Docs utiles : https://docs.openclaw.ai/help/faq et https://docs.openclaw.ai/web/control-ui

[trim schooner]

j'ai la derniere version d'openclaw mes j'aimerais pouvoir le telecharger dans le web ui parce que mon openclaw est a distance

[pearl citrus]

Oui, je vois le besoin : OpenClaw tourne sur une machine distante, donc un chemin local genre /home/.../rapport.pdf ne t’aide pas depuis ton navigateur.

Aujourd’hui le Web/Control UI n’est pas vraiment un gestionnaire de fichiers avec bouton “download” générique. Il sait afficher/servir certains médias assistant via une route authentifiée, mais pour un fichier arbitraire généré par l’agent, ce n’est pas encore une expérience propre.

Workaround possible : demande à l’agent de sauvegarder le fichier dans un dossier média/workspace autorisé, par exemple ~/.openclaw/media/outbound/mon-fichier.pdf, puis récupère-le via la route du gateway :

https://TON_GATEWAY/__openclaw__/assistant-media?source=/home/USER/.openclaw/media/outbound/mon-fichier.pdf

Il faut être authentifié au gateway, et le fichier doit être dans un dossier autorisé (~/.openclaw/media, workspace/sandbox, tmp OpenClaw, etc.). Si le gateway demande un token, évite de partager un lien avec le token dedans.

Pour une vraie fonction “fichier généré → lien/bouton télécharger dans le Web UI”, je pense que ça mérite une issue feature request ici : https://github.com/openclaw/openclaw/issues

[trim schooner]

depuis la derniere mise a jour openclaw des fois est extrement lent meme avec different provider et coupe literalement il secesse de repondre et revien quelque heure plus tard.

[pearl citrus]

Ça ressemble moins à un provider précis qu’à un blocage côté gateway/session, surtout si ça revient plusieurs heures après.

Même si tu es “à jour”, donne la version exacte :

openclaw --version
openclaw status --all
openclaw health --verbose
openclaw gateway status

Et quand ça se bloque, lance/partage le plus petit extrait utile de :

openclaw logs --follow
openclaw gateway stability --bundle latest

[pearl citrus]

À regarder dans les logs : erreurs provider/rate limit, timeouts, mémoire haute, session store, ou une boucle de retry. Si l’UI coupe mais que le gateway répond encore, openclaw health --verbose aide à distinguer “agent lent” vs “gateway bloqué”.

Workaround immédiat si c’est coincé : redémarrer le gateway (openclaw gateway restart) et, si une session précise est corrompue/lourde, tester une nouvelle session. Si tu as des logs montrant un freeze sans erreur claire, ouvre une issue avec version + status --all + extrait de logs : https://github.com/openclaw/openclaw/issues

Docs triage : https://docs.openclaw.ai/help/troubleshooting

[pearl citrus]

Merci, là il y a un signal utile :

! Inbound delivery telemetry: received 11 · dispatch 11/6 · turns 15 · processed 9
Multiple gateway dispatches have not completed yet

Donc le gateway répond bien (event loop ok, probe OK), mais des runs/messages restent coincés. Ça colle avec “ça revient plusieurs heures plus tard”. Vu tes 6 agents, 164 sessions, et plusieurs crons actifs, je regarderais d’abord les sessions/runs bloqués plutôt que les providers.

À faire au moment où c’est lent :

openclaw logs --follow
openclaw gateway stability --bundle latest
openclaw health --verbose

[pearl citrus]

Dans les logs, cherche les lignes autour du message bloqué : provider timeout/rate limit, cron qui part en boucle, subagent coincé, ou une session dashboard/cron qui ne termine jamais.

Workaround propre pour isoler :

openclaw gateway restart

Puis teste avec une nouvelle session dashboard sur un seul agent. Si ça redevient lent dès que les crons repartent, désactive temporairement les crons/heartbeats des agents les plus actifs pour confirmer.

Si tu ouvres une issue, mets exactement ce rapport + un extrait de openclaw logs --follow pendant le blocage. La ligne Multiple gateway dispatches have not completed yet est la partie importante : https://github.com/openclaw/openclaw/issues

[trim schooner]

tu pense que le probleme sont les crons ? parce que actuellement aucun agents repond

[pearl citrus]

Oui, c’est plausible, mais je ne dirais pas encore “certain”. Le rapport montre surtout que des dispatches ne finissent pas. Les crons sont un bon suspect parce que tu as plusieurs agents actifs récemment, des sessions cron:*, et si un cron isolé/subagent reste coincé il peut occuper la file ou saturer les runs.

Pour confirmer sans casser ta config :

openclaw cron status
openclaw cron list
openclaw tasks list
openclaw logs --follow

Si tu vois des jobs/runs actifs depuis longtemps, stoppe d’abord le symptôme :

openclaw gateway restart

[pearl citrus]

Puis test simple : désactive temporairement le scheduler et redémarre, juste pour voir si les agents répondent normalement :

OPENCLAW_SKIP_CRON=1 openclaw gateway restart

Si ton gateway est en service systemd, il faut mettre cette variable dans le service/env systemd, ou plus simple modifier temporairement la config avec cron.enabled: false, puis redémarrer. Si avec les crons coupés tout redevient fluide, on a quasiment la cause.

Docs cron : https://docs.openclaw.ai/automation/cron-jobs

[trim schooner]

Invalid config at /home/frank_macmini/.openclaw/openclaw.json:\n- agents.list.1.identity.avatar: identity.avatar must stay within the agent workspace.

• agents.list.2.identity.avatar: identity.avatar must stay within the agent workspace.
• agents.list.3.identity.avatar: identity.avatar must stay within the agent workspace.
• agents.list.4.identity.avatar: identity.avatar must stay within the agent workspace.
• agents.list.5.identity.avatar: identity.avatar must stay within the agent workspace.

OpenClaw 2026.5.22 (a374c3a) — Half butler, half debugger, full crustacean.

OpenClaw config is invalid
File: ~/.openclaw/openclaw.json
Problem:

• agents.list.1.identity.avatar: identity.avatar must stay within the agent workspace.
• agents.list.2.identity.avatar: identity.avatar must stay within the agent workspace.
• agents.list.3.identity.avatar: identity.avatar must stay within the agent workspace.
• agents.list.4.identity.avatar: identity.avatar must stay within the agent workspace.
• agents.list.5.identity.avatar: identity.avatar must stay within the agent workspace.

Fix: openclaw doctor --fix
Inspect: openclaw config validate
Status, health, logs, and doctor commands still run with invalid config.
Gateway aborted: config is invalid.
agents.list.1.identity.avatar: identity.avatar must stay within the agent workspace.
agents.list.2.identity.avatar: identity.avatar must stay within the agent workspace.
agents.list.3.identity.avatar: identity.avatar must stay within the agent workspace.
agents.list.4.identity.avatar: identity.avatar must stay within the agent workspace.
agents.list.5.identity.avatar: identity.avatar must stay within the agent workspace.
Run "openclaw doctor --fix" to repair, then retry.
If startup is still blocked, inspect the adjacent .bak backup before restoring it manually.
frank_macmini@macmini:~$

[pearl citrus]

Là le problème immédiat n’est plus les crons : le gateway ne démarre pas parce que la config est invalide.

Depuis cette version, agents.list[].identity.avatar doit être soit :

• un chemin relatif dans le workspace de l’agent, ex. avatars/roc.png
• une URL https://...
• un data: URI

Mais pas un chemin absolu hors workspace du genre /home/.../image.png ou ../....

Le fix le plus simple :

openclaw doctor --fix
openclaw config validate
openclaw gateway restart

[pearl citrus]

Si doctor --fix ne règle pas tout, édite ~/.openclaw/openclaw.json et supprime temporairement les lignes identity.avatar des agents 1 à 5, puis :

openclaw config validate
openclaw gateway restart

Si tu veux garder les avatars, mets chaque image dans le workspace de l’agent et référence-la en relatif, par exemple :

identity: {
  avatar: "avatars/avatar.png"
}

Docs config : https://docs.openclaw.ai/gateway/configuration-reference

[trim schooner]

donne moi la config que je dois dire a l'agent pour qu'il me donne les avatar

[pearl citrus]

Dis à ton agent local quelque chose comme ça :

Corrige les avatars OpenClaw dans ~/.openclaw/openclaw.json.
Pour chaque agent dans agents.list, identity.avatar ne doit pas être un chemin absolu.

Pour chaque agent :
1. Trouve son workspace configuré dans agents.list[].workspace.
2. Crée un dossier avatars/ dans ce workspace si besoin.
3. Copie ou génère l’image avatar dans <workspace>/avatars/avatar.png.
4. Dans ~/.openclaw/openclaw.json, mets identity.avatar avec un chemin relatif : "avatars/avatar.png".
5. Lance openclaw config validate puis openclaw gateway restart.
Ne supprime pas les autres réglages.

Exemple de config valide :

[pearl citrus]

agents: {
  list: [
    {
      id: "roc",
      workspace: "/home/frank_macmini/.openclaw/agents/roc/workspace",
      identity: {
        name: "Roc",
        avatar: "avatars/avatar.png"
      }
    }
  ]
}

Important : le fichier réel doit être ici dans cet exemple :

[pearl citrus]

/home/frank_macmini/.openclaw/agents/roc/workspace/avatars/avatar.png

Alternative simple si tu veux juste redémarrer vite : supprime temporairement toutes les clés identity.avatar, valide, puis remets les avatars plus tard.

[trim schooner]

cela va permettre d'avoir les iamge d'avatar dans openclaw controle ui ?

[pearl citrus]

Oui, c’est le but : si identity.avatar pointe vers une image valide dans le workspace de l’agent, le Control UI peut l’afficher pour cet agent.

Le point important est la forme :

identity: {
  name: "Roc",
  avatar: "avatars/avatar.png"
}

Et le fichier doit vraiment exister ici :

<workspace de l’agent>/avatars/avatar.png