Incident-boundary note: this pack covers the March 18, 2026 OpenClaw GitHub impersonation issue cluster. It preserves the reported incident pattern and durable verification advice, but it does not claim the same campaign is live today.
The March 18 OpenClaw GitHub scam wave matters as historical incident evidence because it is easy to misread that pattern as ordinary spam.
It is not.
The March 18 issue cluster points to something more repeatable: new GitHub accounts created look-alike repos, opened discussions that felt official enough to trigger notification trust, name-dropped contributors to simulate legitimacy, and then pushed users toward wallet links, fake airdrops, or other off-platform actions. The payload can change. The pattern can recur.
That is why this pack is preserved from that incident moment. It is for the moment when you need to decide whether a repo, discussion, or token message belongs to the real OpenClaw project, and you do not want to reconstruct the whole trust model from scratch.
Who This Pack Is For
This historical incident packet is most useful if you are in one of three situations:
- you were tagged in a March 18-style GitHub discussion or listed as a supposed recipient of an OpenClaw token or payout,
- you help maintain community surfaces and need a clean way to brief others without turning the incident into rumor soup,
- you are new to OpenClaw and want to know which repo, story, and security guidance to trust before you click anything.
If you only need one sentence of orientation, it is this:
Treat unsolicited OpenClaw token, airdrop, or wallet-sync messages on GitHub as hostile by default, then verify against canonical project surfaces before doing anything else.
Why This Pack Exists For The March 18 Incident
The March 18 issue cluster was tight enough to count as an incident pattern, not a one-off report.
Across #49836, #49861, #49847, and #49845, the same family of signals shows up again and again:
- fresh or low-trust GitHub accounts,
- repo names that look almost right at a glance,
- discussion posts written in quasi-official project language,
- promises of free credits, CLAW tokens, or contributor rewards,
- off-platform links that ask the target to connect a wallet or otherwise act fast.
The important thing here is not whether one account matches another. The important thing is that the campaign shape is stable enough to recognize.
Confidence boundary: the March 18 issue cluster strongly supports the existence of a reported impersonation wave at that time and the mechanics it used. It does not prove whether all reported accounts belonged to one coordinated actor or to multiple opportunists copying the same playbook, and this pack does not add a fresh current-incident claim.
The Baseline Judgment
This is not random spam drifting through developer inboxes.
It is a repeatable attention-to-impersonation pattern that weaponizes three trust shortcuts at once:
- GitHub surface trust — the message arrives where real project activity usually happens.
- Name similarity trust — the repo or account looks plausible for a second too long.
- Urgency trust — the target is pushed toward a wallet, claim, or whitelist action before they switch into verification mode.
That is the reading frame for everything in this packet. If you keep that in view, the linked pages stop looking like separate episodes and start looking like one discovery-and-trust problem with multiple skins.
What The March 18 Wave Looked Like
The March 18 reported wave remains useful because it exposes several distinct scam tells without requiring us to overstate what we know.
The issue evidence includes:
- fake repositories that swap characters such as
0forOorIforl, - GitHub discussions that borrow official-sounding phrases like support-team or member-verification language,
- contributor lists or @mentions designed to make the post feel socially validated,
- links that jump to wallet-connection or whitelist flows unrelated to any official OpenClaw release process.
That means the verification question is usually not “does this sound promotional?” It is:
does this action make sense for how the real OpenClaw project actually ships, communicates, or rewards people?
In these reports, the answer is consistently no.
Recommended Reading Path
Use this packet as a sequence, not a pile.
1) Start with the scam-wave story
Begin with The Security Scam Wave Around OpenClaw.
This is the fastest way to recover the big picture: why copied surfaces mattered so much around OpenClaw, how delegated-action trust made the emotional temperature higher, and why the community kept paying for identity confusion in ways that were not only cosmetic.
2) Then read the fake-installer story
Continue with When Fake OpenClaw Installers Turned Discovery Into the Real Attack Surface.
It sharpens the most useful lesson for this GitHub incident wave: cloned repos are not dangerous only because they exist. They become dangerous when search, recommendation, or platform trust does half the persuasion work for them.
3) Read the token-pattern analysis next
Then read The First Token Is Always a Scam.
This page matters because fake airdrops are not a weird side plot. They are a predictable way to monetize attention quickly once a project name becomes hot enough to imitate.
4) Add the rename background if you need the historical opening
If you want to understand why identity confusion around OpenClaw had so much available fuel, read OpenClaw vs Claude: The Rename Drama That Turned a Repo Into a Soap Opera.
That page is not the incident report for this wave, but it explains why rename turbulence and public argument created a wider scam window than a boring, stable brand usually would.
5) Use the governance lens to avoid treating this as only a moderation problem
Read Attention Is the Attack Surface when you need the larger lesson.
The strongest takeaway is that popularity itself changes the threat model. Governance, identity hygiene, and discovery-path design become security work long before any code exploit appears.
6) Move from incident understanding to operator hardening
Finish with OpenClaw Security Baseline: A Safe Operator Reading Pack.
This incident pack tells you how to interpret the reported wave. The security-baseline pack tells you what to harden next if you operate real surfaces, identities, approvals, or user-facing workflows.
Fast Paths By Situation
If you do not want the full reading sequence, use the path that matches your situation.
If you were tagged in a suspicious GitHub discussion
Read these in order:
- The Security Scam Wave Around OpenClaw
- The First Token Is Always a Scam
- OpenClaw Security Baseline: A Safe Operator Reading Pack
Your main job is not to become a security theorist. It is to avoid clicking, avoid connecting a wallet, and re-anchor your trust in canonical project surfaces.
If you help run community or maintainer-facing surfaces
Read these in order:
- Attention Is the Attack Surface
- The Security Scam Wave Around OpenClaw
- OpenClaw Security Baseline: A Safe Operator Reading Pack
Your job is to turn a messy incident into a simple operating rule set for others: what is official, what is fake, where to report, and what not to do under urgency.
If you are new to OpenClaw and are not sure what is official
Read these in order:
- confirm the canonical repo: openclaw/openclaw
- When Fake OpenClaw Installers Turned Discovery Into the Real Attack Surface
- The Security Scam Wave Around OpenClaw
Your job is to build the right instinct early: a repo that merely looks plausible is not good enough.
The Three Verification Questions That Matter Most
When a message looks urgent and official, ask only these three questions first:
1) Is the repo or account canonically anchored?
If the repo is not the real openclaw/openclaw or clearly tied from canonical project surfaces, treat it as untrusted.
2) Does the action match the project’s real behavior?
OpenClaw issue reports in this wave describe token distributions, contributor payouts, whitelist language, and wallet-sync instructions. None of that fits a normal software-release or docs workflow.
3) Is the post trying to accelerate you past verification?
Urgency is not proof of fraud by itself, but in this cluster it is part of the mechanism. The faster the target is pushed toward an external action, the more important it is to slow the trust decision down.
Common Mistake To Avoid
Do not collapse every OpenClaw scam story into one vague lesson like “be careful online.”
That framing is too weak to help.
The stronger lesson is narrower and more useful:
for OpenClaw, the attack often lands in discovery and identity first, then uses platform trust to drag the target toward an off-platform action.
That is why cloned repos, look-alike names, fake discussions, and wallet lures belong in the same packet.
Closing Baseline
If this reading pack does its job, the next suspicious GitHub notification should feel less confusing.
Not because every scam will look identical, but because the operating frame is now clearer: copied identity plus urgency plus off-platform action is a pattern, not a surprise.
Once you see that, the next move becomes simpler. Verify the surface. Ignore the lure. Then use the linked pages to understand whether you need incident context, discovery context, governance context, or a harder operator baseline.