mirror of
https://github.com/openclaw/openclaw.git
synced 2026-05-06 17:40:44 +00:00
Wire diagnostics through the core chat command (#72936)
* feat: wire codex diagnostics feedback * fix: harden codex diagnostics hints * fix: neutralize codex diagnostics output * fix: tighten codex diagnostics safeguards * fix: bound codex diagnostics feedback output * fix: tighten codex diagnostics throttling * fix: confirm codex diagnostics uploads * docs: clarify codex diagnostics add-on * fix: route diagnostics through core command * fix: tighten diagnostics authorization * fix: pin diagnostics to bundled codex command * fix: limit owner status in plugin commands * fix: scope diagnostics confirmations * fix: scope codex diagnostics cooldowns * fix: harden codex diagnostics ownership scopes * fix: harden diagnostics command trust and display * fix: keep diagnostics command trust internal * fix: clarify diagnostics exec boundary * fix: consume codex diagnostics confirmations atomically * test: include codex diagnostics binding metadata * test: use string codex binding timestamps * fix: keep reserved command trust host-only * fix: harden diagnostics trust and resume hints * wire diagnostics through exec approval * fix: keep diagnostics tests aligned with bundled root trust * fix telegram diagnostics owner auth * route trajectory exports through exec approval * fix trajectory exec command encoding * fix telegram group owner auth * fix export trajectory approval hardening * fix pairing command owner bootstrap * fix telegram owner exec approvals * fix: make diagnostics approval flow pasteable * fix: route native sensitive command followups * fix: invoke diagnostics exports with current cli * fix: refresh exec approval protocol models * fix: list codex diagnostics from thread bindings * fix: fold codex diagnostics into exec approval * fix: preserve diagnostics approval line breaks * docs: clarify diagnostics codex workflow
This commit is contained in:
@@ -7,9 +7,13 @@ read_when:
|
||||
- Reviewing what diagnostics data is recorded or redacted
|
||||
---
|
||||
|
||||
OpenClaw can create a local diagnostics zip that is safe to attach to bug
|
||||
reports. It combines sanitized Gateway status, health, logs, config shape, and
|
||||
recent payload-free stability events.
|
||||
OpenClaw can create a local diagnostics zip for bug reports. It combines
|
||||
sanitized Gateway status, health, logs, config shape, and recent payload-free
|
||||
stability events.
|
||||
|
||||
Treat diagnostics bundles like secrets until you have reviewed them. They are
|
||||
designed to omit or redact payloads and credentials, but they still summarize
|
||||
local Gateway logs and host-level runtime state.
|
||||
|
||||
## Quick start
|
||||
|
||||
@@ -29,6 +33,45 @@ For automation:
|
||||
openclaw gateway diagnostics export --json
|
||||
```
|
||||
|
||||
## Chat command
|
||||
|
||||
Owners can use `/diagnostics [note]` in chat to request a local Gateway export.
|
||||
Use this when the bug happened in a real conversation and you want one
|
||||
copy-pasteable report for support:
|
||||
|
||||
1. Send `/diagnostics` in the conversation where you noticed the problem. Add a
|
||||
short note if it helps, for example `/diagnostics bad tool choice`.
|
||||
2. OpenClaw sends the diagnostics preamble and asks for one explicit exec
|
||||
approval. The approval runs `openclaw gateway diagnostics export --json`.
|
||||
Do not approve diagnostics through an allow-all rule.
|
||||
3. After approval, OpenClaw replies with a pasteable report containing the local
|
||||
bundle path, manifest summary, privacy notes, and relevant session ids.
|
||||
|
||||
In group chats, an owner can still run `/diagnostics`, but OpenClaw does not
|
||||
post the diagnostic details back into the shared chat. It sends the preamble,
|
||||
approval prompts, Gateway export result, and Codex session/thread breakdown to
|
||||
the owner through the private approval route. The group only gets a short notice
|
||||
that the diagnostics flow was sent privately. If OpenClaw cannot find a private
|
||||
owner route, the command fails closed and asks the owner to run it from a DM.
|
||||
|
||||
When the active OpenClaw session is using the native OpenAI Codex harness,
|
||||
the same exec approval also covers an OpenAI feedback upload for the Codex
|
||||
runtime threads OpenClaw knows about. That upload is separate from the local
|
||||
Gateway zip and appears only for Codex harness sessions. Before approval, the
|
||||
prompt explains that approving diagnostics will also send Codex feedback, but it
|
||||
does not list Codex session or thread ids. After approval, the chat reply lists
|
||||
the channels, OpenClaw session ids, Codex thread ids, and local resume commands
|
||||
for the threads that were sent to OpenAI servers. If you deny or ignore the
|
||||
approval, OpenClaw does not run the export, does not send Codex feedback, and
|
||||
does not print the Codex ids.
|
||||
|
||||
That makes the common Codex debugging loop short: notice the bad behavior in
|
||||
Telegram, Discord, or another channel, run `/diagnostics`, approve once, share
|
||||
the report with support, then run the printed `codex resume <thread-id>` command
|
||||
locally if you want to inspect the native Codex thread yourself. See
|
||||
[Codex harness](/plugins/codex-harness#inspect-a-codex-thread-from-the-cli) for
|
||||
that inspection workflow.
|
||||
|
||||
## What the export contains
|
||||
|
||||
The zip includes:
|
||||
|
||||
Reference in New Issue
Block a user