#Nightmare with agents

61 messages · Page 1 of 1 (latest)

fiery oriole
#

Ok so, ive been trying something. i have my normal agent. That ones got all of my context. all of my access to my infrastructure. everything. so that one i dont want people to talk to. i talk to it in telegram. thats all working fine and dandy. I had the main agent setup two other agents which i gave their own discord account. I added them both to a discord server and the people in there can communicate with them fine. Ive been going in circles with opus for like 6 hours troubleshooting this issue. But, i would like people to be able to dm both of those secondary agents. People i explicitly authorize. Importantly, the entire point is so that i can experiment with isolation. Not letting people have access to my infrastructure but only like certain file paths (the agents are lead generation/enrichment and marketing material creation respectively)

So the issue is that no matter what i do, when people i allow dm the bots on discord, they should be able to talk to them in dm. with their own sessions, their own context, with NONE of my personal context. Just a memory path that goes to basically this read only file about the company and what we're doing

Currently no bots respond to any dms on the server but work totally fine in the server. If you have any clarifying questions please ask. and i know this is a lot

dire heronBOT
#

Let me check the docs and source for the Discord DM path.

#

Yeah, this should work, and the fact that guild chat works but DMs are silent narrows it a lot.

Most likely it’s one of these:

  • channels.discord.dm.enabled=false
  • channels.discord.dmPolicy is blocking DMs (disabled, allowlist, or pairing with no approval yet)
  • you put allowFrom on the default Discord account only, but your secondary bots are named accounts
    • channels.discord.accounts.default.allowFrom does not apply to named accounts
    • named accounts inherit channels.discord.allowFrom, or need their own channels.discord.accounts.<id>.allowFrom
  • you used Discord names/tags instead of numeric user IDs in allowFrom
  • the user can DM the bot, but Discord privacy is blocking the pairing reply from reaching them

For your setup, the isolation setting you want is:

session: { dmScope: "per-account-channel-peer" }
#

Not per-channel-peer, because you have multiple Discord accounts on one gateway.

Also, important nuance: dmScope isolates chat context, not host trust. If these users are truly untrusted, separate gateways per trust boundary is the safer model.

A minimal shape for one secondary bot looks like:

{
  session: { dmScope: "per-account-channel-peer" },
  channels: {
    discord: {
      accounts: {
        leadgen: {
          dmPolicy: "allowlist", // or "pairing"
          allowFrom: ["123456789012345678"],
          dm: { enabled: true },
# 
        },
      },
    },
  },
}

If you want owner approval instead of a fixed list, use dmPolicy: "pairing" and approve the first DM.

Can you paste these 4 things and I can zero in fast:

  1. openclaw --version
  2. the redacted channels.discord config for one secondary bot, especially:
    • accounts
    • defaultAccount
    • dm
fiery oriole
#

so far, they have been unable to bypass my strict agents file but youre right. It does feel like specific agent trust should be a feature. I can think of a lot of ways that that i could deploy really cool infrastructure with that

dire heronBOT
#

Yeah, I’m with you, per-agent trust boundaries would be a really good feature.

I’d still treat a strict AGENTS.md as a soft boundary, not the hard wall. The hard wall is separate gateway / sandbox / workspace policy.

For the DM bug though, I think this is still a Discord config/account-scope problem, not a trust-model problem.

The two biggest gotchas for your exact setup are:

  • channels.discord.accounts.default.allowFrom only applies to the default account
  • with multiple Discord bot accounts, you want session.dmScope: "per-account-channel-peer"

So if your bots are named accounts like leadgen and marketing, I’d expect something shaped like:

{
  session: { dmScope: "per-account-channel-peer" },
# 
  channels: {
    discord: {
      accounts: {
        leadgen: {
          dmPolicy: "allowlist", // or "pairing"
          allowFrom: ["123456789012345678"],
          dm: { enabled: true },
        },
        marketing: {
          dmPolicy: "allowlist",
          allowFrom: ["123456789012345678"],
          dm: { enabled: true },
        },
      },
    },
# 
  },
}

Can you paste these and I’ll look for the exact bad line:

  • openclaw --version
  • one redacted channels.discord.accounts.<botId> block
  • session.dmScope
  • openclaw channels status --probe
  • after DMing the bot once: openclaw pairing list discord

Also, super important: when you DM the bot, is it:

  • total silence
  • sends a pairing code
#
  • logs something but sends nothing

If you want the agent-specific trust idea tracked properly, that’s probably worth a GitHub issue too: https://github.com/openclaw/openclaw/issues

Paste the config, I’ll go line by line.

fiery oriole
dire heronBOT
#

I’m pulling the paste and checking the config shape now.

#

This was enough, and honestly it helps a lot.

Your marketing and leads Discord account blocks look basically correct to me:

  • dmPolicy: "allowlist"
  • account-level allowFrom
  • dm: { enabled: true }
  • bindings by accountId
  • session.dmScope: "per-account-channel-peer"

So I don’t think the main problem is your agent bindings or DM session isolation.

The next best test is this, because it splits the problem in half immediately:

openclaw message send --channel discord --account marketing --target user:<YOUR_USER_ID> --message "marketing dm test"
# 
openclaw message send --channel discord --account leads --target user:<YOUR_USER_ID> --message "leads dm test"

Two outcomes:

  • If those fail, the problem is outbound Discord DM delivery from those bot accounts
    • most likely Discord privacy setting / DM permission behavior
    • each user should enable server icon → Privacy Settings → Direct Messages
  • If those succeed, the problem is inbound DM auth/routing, not delivery

A couple of specific notes from your paste:

  • since marketing and leads use dmPolicy: "allowlist", openclaw pairing list discord is not the right debug path for those two
  • make sure the real allowFrom entries are quoted strings, not bare numbers, because Discord snowflakes are too large to safely use as JS numbers
  • the only config smell I see is accounts.default.dmPolicy: "allowlist" without a visible allowFrom, but that shouldn’t block marketing / leads DMs
#

So my ask now is just:

  1. run those two openclaw message send tests
  2. tell me whether they arrive
  3. if they do not arrive, tell me whether your Discord user has Direct Messages enabled for that server

If you want, after that I can give you a very small next-step matrix instead of making you keep guessing.

fiery oriole
#

ok some interesting data. So i can do the test sends through BOTH leads and marketing to both myself AND my friend

but he still gets radio silence when he dms them. not even a typing indicator

#

okie dokie, hold on. just noticed, i can dm both the leads and marketing. looks like its working fine for me. still not sure why its not working for my friend.

dire heronBOT
#

That’s actually a really useful data point.

If both bots can send DMs to both people, then token/account binding/outbound delivery are probably fine. This is now very likely an inbound DM auth/ingress issue.

My first suspect now is this exact footgun:

allowFrom: ["472430991496183809"] // good
allowFrom: [472430991496183809]   // bad for Discord snowflakes

Discord IDs need to be quoted strings. Bare numeric IDs can get precision-loss and then never match inbound DMs.

Please run these next:

# 
openclaw --version
openclaw doctor
openclaw channels status --probe

If doctor mentions Discord numeric IDs, run:

openclaw doctor --fix
openclaw gateway restart

Then tail logs and have your friend DM one bot once:

# 
openclaw logs --follow

What I’m looking for in logs:

  • Blocked unauthorized discord sender ... → allowlist mismatch
  • discord: drop dm (dms disabled) or dmPolicy: disabled → wrong resolved account config
  • nothing at all when they DM → the DM event is not reaching that bot listener

If you want, paste just one of these blocks exactly as it exists now:

  • channels.discord.accounts.marketing
  • channels.discord.accounts.leads

and I’ll sanity check the shape fast.

#

Oh, that’s great. That narrows it a lot.

If you can DM both bots now, then the DM pipeline itself is working. So this is almost certainly just a per-user allowlist mismatch for your friend, not a broader Discord DM bug.

I’d check these 3 things next:

  1. Friend’s exact Discord user ID is in both account allowlists
    Use the numeric ID, not username/tag.

  2. The ID is a quoted string, not a bare number

    allowFrom: ["123456789012345678"] // good
allowFrom: [123456789012345678]   // bad

  3. The friend is added to the right account blocks

    • channels.discord.accounts.marketing.allowFrom
#
  • channels.discord.accounts.leads.allowFrom

If you change config, restart once:

openclaw gateway restart

At this point I would ignore session.dmScope and isolation stuff for a minute. That part is probably fine. This now smells like: “you are allowlisted, your friend isn’t matching.”

If you want, paste just the two allowFrom arrays and I can sanity check them quickly. Also still worth grabbing:

openclaw --version
openclaw doctor
fiery oriole
#

Config looks correct on our end but thatch still gets radio silence. Confirmed his ID is the numeric snowflake copied directly from his profile. Both allowFrom arrays look like this:

"allowFrom": [
"161664895006277634",
"472430991496183809"
]
Both are quoted strings. Both accounts (marketing and leads) have identical arrays. I can DM both bots fine with my own ID which is the second one in that list.

Full discord account shape for one of the secondary bots:

"marketing": {
"token": "[REDACTED]",
"guilds": {
"[GUILD-ID]": {
"requireMention": true,
"channels": {
"[CHANNEL-ID]": { "allow": true, "requireMention": true }
}
}
},
"dmPolicy": "allowlist",
"allowFrom": ["161664895006277634", "472430991496183809"],
"dm": { "enabled": true }
}
Top-level discord config also has "defaultAccount": "default" and "groupPolicy": "allowlist". Session dmScope is "per-account-channel-peer".

When thatch DMs — total silence, nothing in logs, no pairing prompt, nothing on his end either.

also my version is OpenClaw 2026.4.12 (1c0672b)

dire heronBOT
#

This is actually really helpful. If you can DM both bots, the config shape is basically vindicated.

At this point I’d treat it as one of two things:

  1. Gateway listener/dispatch bug
  2. The friend’s reply is not actually landing in the bot DM thread you think it is

The cleanest next probe is this, right after thatch sends a fresh DM:

openclaw message read --channel discord --account marketing --target user:161664895006277634 --limit 5
openclaw message read --channel discord --account leads --target user:161664895006277634 --limit 5

Interpretation:

  • If his inbound message shows up there, Discord can see the DM, and the bug is in the gateway inbound path.
#
  • If it does not show up there, the reply is not reaching that bot account’s DM conversation at all.

Also, one important bit: “nothing in logs” is weaker than it sounds here, because a lot of the DM drop lines are verbose-only. So I trust message read more than silence in normal logs.

And, I’m a little suspicious of your exact version. You’re on 2026.4.12, and a Discord inbound-worker fix landed immediately after that build. I can’t promise that’s the bug, but honestly, with your config looking sane, I would update to latest once before losing another 6 hours.

So my recommendation is:

  1. run the two message read probes
  2. if the messages are visible, update OpenClaw and restart the gateway
  3. if they are not visible, focus on the Discord side / DM thread itself, not OpenClaw auth

If you paste the output of those two message read commands, I can probably tell you which side is broken pretty fast.

fiery oriole
#

Error: Discord channel id is required (use channel:<id>).

dire heronBOT
#

Yep, that one’s on me. For Discord, message read wants a DM channel id, not user:<id>.

Do it like this:

  1. Send a test DM and ask for JSON back:
openclaw message send --channel discord --account marketing --target user:161664895006277634 --message "debug ping" --json

  1. In the JSON result, grab the returned channelId.

  2. Then read that DM thread directly:

openclaw message read --channel discord --account marketing --target channel:<THAT_CHANNEL_ID> --limit 10

Same idea for leads if you want to test both.

#

What this tells us:

  • If Thatch’s reply shows up in message read, Discord is receiving it and this points back at the inbound listener/worker path. In that case I’d really try updating past 2026.4.12.
  • If his reply does not show up there, then Discord is not putting his reply into that bot DM channel, which means this is not an OpenClaw auth problem.

If you paste the JSON from the send --json and then the read output, I can help interpret it.

fiery oriole
#

Ok so i did the read, and yeah i see all of his messagees to it

dire heronBOT
#

Perfect, that basically proves it.

If message read can see his inbound DMs, then:

  • Discord auth is fine
  • allowFrom is fine
  • the DM is landing in the right bot conversation
  • this is not a config/isolation problem anymore

So the bug is almost certainly in the live inbound Discord listener/worker path on your gateway, not in your config. And with you being on 2026.4.12, I’d stop burning time on config and update OpenClaw first.

My recommendation now:

  1. Update to latest
  2. Restart the gateway
# 
   openclaw gateway restart
  1. Retest the friend DM

If it still fails after updating, I’d call this a legit bug and file it here:

https://github.com/openclaw/openclaw/issues

Include this exact summary:

  • OpenClaw 2026.4.12
  • multi-account Discord setup
  • guild chat works
  • bot can send DMs outbound
  • message read sees the friend’s inbound DM messages
  • live DM handling stays silent
#

That’s a really strong repro.

So, short version: your config looks right, this now smells like a Discord inbound runtime bug.

fiery oriole
#

if it was a bug, why can it handle responding to me and not him? im updating anyway but it smells fishy to me

dire heronBOT
#

Yeah, that’s a fair objection. I’d be suspicious too.

But a bug here would not have to be global. It can be per DM conversation.

The important bit is that the live route is keyed off things like:

  • account
  • DM channel
  • peer/user
  • session/binding state

So it’s totally possible for:

  • your DM route to be healthy
  • his DM route to be wedged or mis-bound

while both messages still exist in Discord and show up via message read.

#

That’s why message read was useful. It proves:

  • Discord got his messages
  • the bot account can see them
  • the failure is in the live handling path for that conversation, not “Discord DMs are broken”

So “bug” here really means something like:

  • stale per-user DM binding
  • bad session state for that DM channel
  • inbound worker/routing issue that only hits that conversation key

Which actually fits your symptoms pretty well.

So I think updating is still the right first move.

If it still happens after updating, then I’d specifically suspect stale conversation/session state for Thatch’s DM, and I’d want to know just two things:

#
  1. Had Thatch ever DMed these bots before the current config/setup?
  2. Does a third Discord user work, or do they fail like Thatch?

That split would tell us a lot:

  • only Thatch fails → very likely stale per-conversation state
  • all non-you users fail → broader inbound auth/routing bug

So yes, fishy, but still very plausibly a bug. Just a stateful, per-user one, not a universal one.

fiery oriole
#

Ok ive updated, is he just free and clear to dm or doees he neeed to do /new

dire heronBOT
#

He should be able to just DM normally now.

/new is not required for the update to take effect, the gateway restart already handled that.

That said, if you want the cleanest possible test, I’d do this:

  1. have him DM the bot normally once
  2. if it still acts weird or stays silent, send /new as a standalone message in that DM
  3. then send the real prompt

So, short version:

  • update/restart = enough for code/config changes
  • /new = only for clearing/resetting that conversation’s session state

If I were testing this, I’d probably try one normal DM first, then /new only if it still misbehaves.

fiery oriole
#

fucking hell. still not working even post update. even with a /new

dire heronBOT
#

Ugh, that’s frustrating.

At this point I’d stop guessing and check whether his DM is creating the session you expect.

Right after Thatch sends one fresh DM, run:

openclaw sessions --all-agents --json | grep 161664895006277634

With session.dmScope: "per-account-channel-peer", you should see a session key shaped roughly like:

agent:<agentId>:discord:<accountId>:direct:161664895006277634

That one command tells us a lot:

#

  • No match at all
    → the live Discord inbound path is dying before session routing

  • Match exists, but under the wrong agent/account
    → binding/routing is wrong

  • Match exists under the right agent/account
    → the DM is reaching the session layer, and the failure is deeper in that bound agent/session

So yeah, I’m with you, it’s fishy. But this is the fastest way to stop hand-waving and see where it’s failing.

If you paste the matching line(s), I can tell you what bucket you’re in.

fiery oriole
#

"key": "agent:marketing:discord:marketing:direct:161664895006277634",
"key": "agent:leads:discord:leads:direct:161664895006277634",
"key": "agent:main:discord:leads:direct:161664895006277634",
"key": "agent:main:discord:marketing:direct:161664895006277634",
"key": "agent:leads:discord:direct:161664895006277634",

dire heronBOT
#

Okay, that’s the smoking gun.

For one Discord user, with dmScope: "per-account-channel-peer", you should not be seeing five different session keys.

The two that look correct are:

  • agent:marketing:discord:marketing:direct:161664895006277634
  • agent:leads:discord:leads:direct:161664895006277634

These look stale / legacy / wrong for your current setup:

  • agent:main:discord:leads:direct:...
  • agent:main:discord:marketing:direct:...
  • agent:leads:discord:direct:...

So this is not “DM auth is broken”. It’s more like session-route drift for that user, probably from earlier config/binding/scope changes.

#

My recommendation:

  1. Do not keep tweaking allowFrom, that part is fine.
  2. Open a GitHub issue, because this is now strong maintainer-grade evidence:
    https://github.com/openclaw/openclaw/issues
  3. Include exactly those session keys, plus:
    • message read sees the user’s DMs
    • guild chat works
    • your own DMs work
    • the affected user has multiple session keys, including stale-looking ones

One extra sanity check, if you want:

  • grep your own user ID too
  • if you only get the two “correct” keys for yourself, that seals it even harder

I think we’ve narrowed this down about as far as supportfully possible. This looks like a real routing/session-state bug.

fiery oriole
#

"key": "agent:marketing:discord:marketing:direct:472430991496183809",
"key": "agent:main:discord:leads:direct:472430991496183809",
"key": "agent:main:discord:marketing:direct:472430991496183809",
"key": "agent:leads:discord:leads:direct:472430991496183809",
"key": "agent:main:discord:direct:472430991496183809",

dire heronBOT
#

Okay, that changes my read a bit.

You also have multiple historical keys, so “duplicate keys exist” by itself is not enough to explain why only Thatch fails.

The part that still stands out is this difference:

  • you have a stray agent:main:discord:direct:472430...
  • Thatch has a stray agent:leads:discord:direct:161664...

That weird unscoped agent:leads:discord:direct:<id> key is now my main suspect.

So my updated take is:

  • historical key clutter exists for both of you
  • but his live DM may be resolving onto the wrong old route
  • specifically, that old leads:discord:direct:<id> session
#

If you’ve got one more debugging round in you, this is the sharpest last check:

  1. have Thatch send one fresh DM
  2. dump the matching session blocks with a bit of surrounding context, not just the keys

For example:

openclaw sessions --all-agents --json > /tmp/oc-sessions.json
sed -n '/161664895006277634/,+12p' /tmp/oc-sessions.json

I want to see which entry got the newest activity / timestamps / counters.

If the one advancing is:

# 
agent:leads:discord:direct:161664895006277634

then I think we’ve basically nailed it: his DM is being routed onto an old unscoped leads session.

If you’re too done with this, honestly fair. At that point I’d file the issue with both key sets and call out that only the affected user has the stray unscoped agent:leads:discord:direct:<id> route:

https://github.com/openclaw/openclaw/issues

That’s much stronger than the earlier evidence.

fiery oriole
#

openclaw sessions --all-agents --json > /tmp/oc-sessions.json
sed -n '/161664895006277634/,+12p' /tmp/oc-sessions.json
Config warnings:\n- plugins.entries.logging-enforcer: plugin disabled (disabled in config) but config is present

  • plugins.entries.memory-writer-diagnostic: plugin disabled (disabled in config) but config is present
    "key": "agent:leads:discord:leads:direct:161664895006277634",
    "updatedAt": 1776214197136,
    "ageMs": 13534,
    "sessionId": "0b12ee6f-aaa3-4f35-a132-3559d5867776",
    "systemSent": true,
    "abortedLastRun": false,
    "inputTokens": 1256,
    "outputTokens": 36,
    "totalTokens": 12274,
    "totalTokensFresh": true,
    "model": "glm-5-turbo",
    "modelProvider": "zai",
    "contextTokens": 200000,
    "key": "agent:marketing:discord:marketing:direct:161664895006277634",
    "updatedAt": 1776213501527,
    "ageMs": 709138,
    "sessionId": "b2b8e81a-86ef-4e4d-a776-b4a703ea0e58",
    "systemSent": true,
    "abortedLastRun": false,
    "inputTokens": 3161,
    "outputTokens": 3,
    "totalTokens": 11170,
    "totalTokensFresh": true,
    "model": "glm-5-turbo",
    "modelProvider": "zai",
    "contextTokens": 200000,
    "key": "agent:main:discord:leads:direct:161664895006277634",
    "updatedAt": 1776211345755,
    "ageMs": 2864907,
    "sessionId": "74595940-fcb2-4c48-a5a6-6aefffb39b0c",
    "totalTokens": null,
    "totalTokensFresh": false,
    "model": "glm-5-turbo",
    "contextTokens": 200000,
    "agentId": "main",
    "kind": "direct"
    },
    {
    "key": "agent:main:discord:leads:direct:472430991496183809",
    "key": "agent:main:discord:marketing:direct:161664895006277634",
    "updatedAt": 1776211219531,
    "ageMs": 2991131,
    "sessionId": "b5972c37-31c5-477e-81d2-4fbaad19a7af",
    "totalTokens": null,
    "totalTokensFresh": false,
    "model": "glm-5-turbo",
    "contextTokens": 200000,
    "agentId": "main",
    "kind": "direct"
    },
    {
    "key": "agent:main:discord:marketing:direct:472430991496183809",
    "key": "agent:leads:discord:direct:161664895006277634",
    "updatedAt": 1776184493998,
    "ageMs": 29716672,
    "sessionId": "d97a764f-584d-44ba-bf74-0f8d369624b9",
    "systemSent": true,
    "abortedLastRun": false,
    "inputTokens": 11171,
    "outputTokens": 44,
    "totalTokens": 11672,
    "totalTokensFresh": true,
    "model": "glm-5-turbo",
    "modelProvider": "zai",
    "contextTokens": 200000,
dire heronBOT
#

Okay, this is actually very clarifying, and I need to correct my last guess.

The active session is:

agent:leads:discord:leads:direct:161664895006277634

That one updated 13 seconds ago.

The weird old unscoped one:

agent:leads:discord:direct:161664895006277634

is stale. It has not been touched for hours.

#

So the live DM is not being routed to the wrong old session after all.

That means we’ve now narrowed it down even further:

  • Discord receives his DM
  • OpenClaw sees his DM
  • it routes into the correct scoped leads session
  • but the reply still never makes it back to him

So the remaining failure is basically one of these:

  1. the run inside that session fails silently
  2. the run succeeds but reply dispatch/delivery back to Discord DM is broken

And honestly, with the evidence you’ve gathered, I think this is now firmly GitHub issue territory:

https://github.com/openclaw/openclaw/issues

#

If you want one last read-only check before filing, do this:

  1. dump a bit more of that session block so you get the sessionFile / transcript path
  2. tail the transcript

If there’s an assistant reply in the transcript, then the agent answered and delivery failed.
If there’s no assistant reply, then the run itself is failing inside the session.

But you already have a very solid bug report now. I’d include:

  • message read sees the friend’s DMs
  • correct scoped session key updates on each friend DM
  • manual outbound message send to that friend works
  • live reply never appears in Discord DM

That’s a really sharp repro.

fiery oriole
#

ok ok ok hold on. he got a response when he dmed leads. no response on marketing

dire heronBOT
#

Oh hell yes, that’s actually big.

That means:

  • Discord DMs are not globally broken
  • allowFrom is not globally broken
  • the friend is not globally blocked
  • this is now narrowed to marketing specifically

And your earlier session dump already hinted that:

  • agent:leads:discord:leads:direct:161... was updating
  • agent:marketing:discord:marketing:direct:161... was stale

So the next check is very clean:

  1. have him send one fresh DM to marketing
#
  1. immediately rerun:
openclaw sessions --all-agents --json > /tmp/oc-sessions.json
sed -n '/161664895006277634/,+20p' /tmp/oc-sessions.json

What I want to know is which marketing-related key moves:

  • agent:marketing:discord:marketing:direct:161...
  • agent:main:discord:marketing:direct:161...

Interpretation:

  • marketing scoped key updates
    → marketing session is getting the message, failure is inside that session or its reply delivery
#

  • main marketing key updates instead
    → marketing DM is routing to the wrong agent/session

  • nothing marketing-related updates, but message read still sees the DM
    → marketing inbound live dispatch is broken specifically for that account

This is actually good progress. You’re not debugging “Discord DMs” anymore, you’re debugging one account path.

fiery oriole
#

ok genuinely what the fuck. marketing and leads are now both working despite us changing nothing in the last half hour

dire heronBOT
#

Honestly, that’s infuriating, but it also tells us something important:

it was almost certainly runtime/state weirdness, not your config.

If it starts working without any config change, the likely culprits are stuff like:

  • stale listener/session state
  • delayed reconnect / warmup after update
  • Discord DM route/cache finally settling
  • a stuck session/binding that got shaken loose by restart + fresh traffic

So I would do exactly this now:

  1. Stop changing config
  2. Test both bots a couple more times
  3. If they stay good, call it fixed by update + restart + state shakeout
  4. If it regresses, file the GitHub issue with all the evidence you gathered, because this still smells like a real bug