Create a Redacted Hermes Debug Packet
A useful support packet explains the environment, reproduces the failure, and includes the smallest relevant evidence. It should not be a wholesale copy of the Hermes home directory. Configuration, session exports, gateway logs, and screenshots can contain credentials, user identifiers, private prompts, and filesystem paths.
Official documentation: https://hermes-agent.nousresearch.com/docs/reference/cli-commands#hermes-debug
Build evidence in layers
Start with hermes doctor for dependency and configuration checks. Use hermes status --all to identify running components. hermes dump produces a copy-pasteable setup summary, while hermes debug can assemble a broader diagnostic report. Use hermes logs with time, severity, session, and line limits to capture only the incident window.
Record the exact failing command, timestamp with timezone, expected result, actual result, and whether the problem reproduces in a fresh session. Include versions and the active profile name, but do not include API keys, OAuth tokens, pairing files, customer data, or unrelated conversation history.
Privacy checklist
- Reproduce with neutral test data when possible.
- State the active profile without copying its secret store.
- Run built-in diagnostics before manual log collection.
- Limit logs to the incident window and relevant session.
- Replace home paths, emails, phone numbers, hostnames, and IDs when unnecessary.
- Use redacted session-export options if conversation context is essential.
- Open the final artifact and search for token-like strings.
- Share through the narrowest appropriate support channel.
Make the packet actionable
A good packet answers five questions: what changed, what failed, where it ran, how to reproduce it, and what was already tried. Avoid speculative root causes in the evidence section. Separate observations from hypotheses so maintainers can trust the chronology.
Common pitfalls
- Uploading the entire
.hermesdirectory. - Copying
.env,auth.json, MCP tokens, or pairing data. - Sending thousands of unrelated log lines.
- Redacting the visible value but leaving it in filenames or metadata.
- Omitting timezone and profile information.
- Reporting a failure from an old session without trying a clean one.
Verification steps
- Unpack or open the final report exactly as the recipient will receive it.
- Search for common secret prefixes, bearer headers, email addresses, and home-directory paths.
- Follow the reproduction steps on a clean session.
- Confirm the packet contains the relevant error and surrounding events.
- Verify removing private material did not remove the evidence needed to diagnose the issue.
- Revoke any credential immediately if accidental exposure is discovered.
