Four iteration rounds on a security scanner I run, all of them visible. Here is what the loop actually looks like.

This is a worked example of running a continuous security scanner on a public surface and being wrong, in both directions, in close succession. The scanner is AgentScore, which scans MCP packages on npm and publishes a public security record. Over four days in mid-May 2026 it went through three corrections: an over-flagged class, a too-broad mitigator pass that produced a false negative on a known-credential-leak package, and a fresh sample-check that uncovered new sanitiser patterns we had not yet recognised. Each correction is in the public changelog. None of them was silent.

The point of the post is the loop, not the resolution.

What the data looked like on 2026-05-15

A class-tracker counts how many MCP packages have HIGH command_injection findings in a rolling 7-day window. Mid-April that number was a handful. Mid-May it was 31 distinct packages. Most were in the browser, CLI, or terminal-automation segment, where shell execution is genuinely common because the packages drive other CLIs.

The first hypothesis was real maintainer drift: maybe enough package authors in this segment were writing unsafe ${...} shell wrappers that the public-record arc had a story.

The second hypothesis, which became more probable when one more advisory took the count to 31 distinct packages, was that the scanner’s regex was over-flagging legitimate template-literal patterns. Thirty distinct maintainers all genuinely shipping unsafe shell exec in 30 days, in a community of ~1,300 packages, would be an ecosystem failure. More likely the scanner had a false-positive class.

The actual answer, after four rounds of work over 96 hours, turned out to be mixed. Some of the 31 were false positives the scanner could downgrade with new context-aware mitigators. Some were real static-analysis hits in single-user CLI threat models that the scanner correctly continued to flag. The post is about how I got from “31 packages, hypothesis unclear” to “scanner correctly distinguishes which is which” and what each iteration round had to fix.

Round 1: the initial sample audit

The first move on 2026-05-16 was to manually inspect a sample of the flagged packages. Five were picked across the class: safari-mcp, brave-real-browser-mcp-server, memoir-cli, s3db.js, and claude-flow. Each was rescanned by hand against the regex that originally flagged them.

Of the five samples, four had patterns the scanner was catching incorrectly. Examples:

• A postinstall script invoking codesign against an internal helper path constructed via path.join(__dirname, ...). Not user-controllable.
• A this.exec(SELECT ${fields} FROM …) SQL query in a sqlite client. Not a child process call at all.
• Hardcoded ALL_CAPS module constants like ${REPO_URL} interpolated for readability. Not user input.
• A numeric ID from a GitHub webhook payload (event.pull_request.number). Cannot carry shell metacharacters.
• A .md file titled v3-security-architect.md with the line literally annotated // ❌ Dangerous: shell injection possible as a teaching example. The scanner caught a security tutorial.

Initial estimated false-positive rate on the sample: high, but the number itself ended up being revised twice over the next 48 hours as the scope of “false positive” tightened.

Rounds 2 and 3: shipping the fix, then catching the fix’s bugs

Three corrective passes shipped within hours of each other on 2026-05-16. Each was followed by external review that caught a structural issue in the previous one.

Pattern-level mitigators (round 1 of these three). Seven extensions to the existing sanitizer category (recognise this.exec, __dirname, ${ALL_CAPS}, numeric coercion, code-signing toolchain, npm auto-update patterns) plus a new documentation_context category for markdown code fences and anti-pattern annotations. A local verifier reported 100% suppression on the five-package sample.

Per-file iteration (round 2, caught by review): the 100% was an artifact. The scanner had been reading the gunzipped tarball as one buffer and running mitigators against a ±2000 character window in that buffer. A README heading three files away could downgrade a real finding in another file. The fix: walk the tar archive entry-by-entry, run mitigators against each file’s own content only. Re-verification: still 100%.

All-matches per file (round 3, caught by review again): even per-file, single-match-per-file was masking. The scanner ran each pattern as a single .exec() per file, so an early benign shell call in a file would silently hide a later real unsafe one in the same file. Replaced with an all-matches walk that scores each match independently and keeps the worst-severity result. Re-verification: 75 percent, not 100.

The honest number was 75. [email protected] actually does contain exec(open “${url}”) in upgrade.js and execSync(git clone ${config.gitRepo} .) in diff.js. In a single-user CLI threat model these are benign because the user is attacking only themselves. But the scanner cannot infer the threat model from static analysis, and the flag is correct at that level.

The previous “100%” claim was a measurement bug, not progress.

What I did with the historic advisories

Two paths were possible.

Option A: rewrite each of the affected advisories to the corrected severity. Clean for the casual reader. But quietly editing past records contradicts the public-correction-loop principle that is literally on the methodology page.

Option B: keep the original advisories visible at their original severity, add a correction record at the top of the advisories page pointing readers to the mitigator changelog, and let the live /report/<package> pages reflect the corrected severity once the monitor cron re-scans each affected package over the following 3-4 days.

I took Option B. The yellow correction banner on /security/advisories reads:

The scanner shipped a precision pass on 2026-05-16 targeting a self-detected false-positive class in browser/CLI/terminal MCP packages. Advisories below published before that pass on the affected class remain visible at their original severity. The live /report/<package> page will reflect the corrected severity once the monitor cron rescans that package. Until then, the cached scan-history value on the report page may still show the pre-mitigator severity. We do not silently rewrite the public record.

The mitigator changelog at /scanner/precision carries the May 16 mitigator-pass entry AND a follow-up entry documenting the per-file iteration and the corrected 75 percent suppression number. Both are on the public surface. Neither was edited after the fact.

What rounds 1 to 3 proved

It did not prove the scanner was correct. It proved three other things.

One: the in-class running count plus a sample audit is enough to detect a false-positive class before it does serious damage to credibility. I caught this in a 30-day window with no maintainer pushing back.

Two: the iteration loop works on me, not just on the packages I scan. The same /scanner/precision page that documents mitigators shipped in response to maintainers like Agions and HomenShum now carries an entry where the trigger was my own internal review.

Three: refusing to silently rewrite history is uncomfortable but it is the only credibility move. A reader who finds an old advisory on a package and a corrected scan on the live report page can see the gap and the correction note explaining it. They do not have to trust that the system always told the truth. They can read both versions and decide.

Round 4 (the false-negative correction, 48 hours later)

The work above was substantially complete after the 2026-05-16 fix. Two days later it needed an update, because the fix itself had introduced a false negative.

The new documentation_context mitigator category shipped on 2026-05-16 included a markdown-heading pattern /^#{1,4}s+S/m. That regex matches markdown headings. It also matches YAML comments, shell-script comments, TOML headers, and anything else that starts with #. Without a filename gate, the category fired on any file that happened to contain a #-prefixed line within 2000 characters of a real finding.

Concrete miss: fa-mcp-sdk, the package whose config/local.yaml we publicly disclosed in late April for shipping credentials in the published tarball, scored 30 / HIGH on every scan from April 25 through May 13. On May 17 a fresh scan with the new v2.2 ruleset returned 65 / ELEVATED. The CRITICAL hardcoded_secret finding was now MEDIUM. Looking at it on May 18 morning, the digest showed a score recovery that looked like maintainer action after four weeks of silence. It was not. The YAML file’s own header comments matched the markdown-heading regex, the documentation_context mitigator fired, and the credentials we’d publicly disclosed were silently downgraded by our own scanner.

Two other packages had the same effect with materially-changed public severity (mcpbrowser and opencode-gitlab-dap). Four more had the same misfire but their findings were already correctly downgraded by parallel sanitizer mitigators, so the public score did not move.

The fix was a six-line patch: a CATEGORY_FILE_GATES table that requires documentation_context patterns to fire only on files whose extension is .md, .mdx, .markdown, .rst, .txt, .adoc, or .asciidoc. Other mitigator categories were not file-gated because their patterns are tied to language syntax that does not overlap with comment characters in other languages.

Within the same morning, I rescanned the seven affected packages with the fixed scanner and pushed the corrected scan_history rows. fa-mcp-sdk is back at 45 / HIGH with the CRITICAL credential finding restored. The /scanner/precision changelog carries a new entry documenting the fix exactly the same way the original false-positive entry was documented two days earlier.

So now the public correction record contains two entries: one for an over-correction on the false-positive side that affected 31 advisories, and one for an under-correction on the false-negative side that affected 3 public scores. Both visible. Neither rewritten silently.

The pattern this surfaces: precision passes on a scanner have a natural overshoot. You catch a class of false positives, you ship mitigators, the mitigators are slightly too broad, you catch the resulting false negatives, you tighten. The thing that makes this a credibility move rather than a credibility cost is doing all of it on the public surface, where readers can audit the shape of the correction loop rather than trust that we always told them the truth.

What’s reproducible

The mitigator commits are public. The 5-package sample is version-pinned in scripts/verify-mitigators.cjs so the precision claim can be reproduced. The pattern tracker is at scripts/track-command-injection-pattern.cjs. The corrected scanner is at SCANNER_VERSION = 2.2 in src/lib/kya/scanner.js, with the May 18 file-gate fix in the same file. The list of 7 affected packages and their corrected scores is in the /scanner/precision changelog entry dated 2026-05-18.

The 31 historic advisories are still at /security/advisories with the correction banner pointing at the changelog.

What the tracker count actually stabilised at

Three days after the May 16 mitigator pass, the running count in the browser/CLI command_injection class dropped from 31 to 14 in 48 hours. We expected it to keep dropping toward zero as the v2.2 scanner propagated through the corpus.

It did not. The count moved back up to around 20 and stayed there.

The naive read of that is “the fix did not work.” The honest read is different. The tracker counts packages with HIGH command_injection findings the scanner did NOT downgrade. If the v2.2 + file-gate mitigators are working, FPs disappear from the count and only real-pattern hits remain. The count stabilising at roughly 20 means the underlying rate at which real template-literal shell-exec patterns appear in new browser/CLI MCP publishes is about 20 packages per rolling 7-day window. That is the ecosystem’s actual signal, not our scanner’s failure.

To verify, we sampled 5 packages from the post-fix corpus: beecork, memex-mvp, @piyushdua/engram-dev, agentic-flow, @kevinrabun/judges. Manual inspection of each:

• beecork wraps a user-config-derived bin name into execSync(${whichCmd} ${bin}) in dist/cli/doctor.js. Real static-analysis hit. The threat model is single-user CLI (the user is configuring their own tool), so the practical risk is low, but the scanner correctly cannot infer that.

• memex-mvp does execSync(launchctl unload ${JSON.stringify(PLIST_PATH)}). JSON.stringify wraps the value in escaped double quotes, which is a shell-safe quoting technique. False positive that the scanner did not yet recognise as a sanitiser.

• @piyushdua/engram-dev does execSync(git worktree remove ${shellQuote(record.path)}). The maintainer is explicitly wrapping input in shellQuote(). False positive that the scanner did not yet recognise as a sanitiser.

• agentic-flow does execSync(gh ${args.join(‘ ‘)}) in .claude/helpers/github-safe.js. args is process.argv. Real static-analysis hit in a CLI threat model.

• @kevinrabun/judges is a code-judging benchmark tool. The dangerous-looking code is embedded as STRING LITERALS in a fixture array (expectedRuleIds: ["AUTH-001", ...]), specifically as test corpus for the tool to detect. False positive that the scanner did not yet recognise as a fixture marker pattern.

3 of 5 are false positives the scanner could downgrade with additional mitigator patterns. 2 of 5 are real interpolation-into-shell patterns the scanner correctly keeps flagged at HIGH.

The third precision pass shipped today, 2026-05-19, adds the missing mitigators:

• shellQuote(), shell_quote, shq.quote(, require('shell-quote') as sanitiser patterns
• ${JSON.stringify(...)} directly inside the interpolation slot as a sanitiser pattern
• expectedRuleIds:, dangerousPatterns:, benchmarkCases: as test-fixture markers
• File-path heuristics for benchmark*.js, rules*.js, judges*.js that contain detection corpora
• A meta-template marker: source containing both backslash-escaped backticks and backslash-escaped ${ interpolation markers in close proximity. That combination means the surrounding string is a template literal embedded as string data, e.g. a code-judging tool’s test fixture where the dangerous-looking code is corpus to be detected rather than executable code.

After this third pass, the 5-package post-fix sample suppression rate is 60 percent. Two stay at HIGH because they really are real-pattern hits in single-user CLI threat models. The remaining count in the tracker now reflects something closer to the genuine rate of real template-literal shell exec in new browser/CLI MCP publishes, not measurement noise.

What the iteration loop actually looks like

Four rounds of precision work in 96 hours:

Each round was prompted by either a fresh sample audit or a peer review noticing a structural issue with the previous round. None of the rounds were silent. Each one shipped a /scanner/precision changelog entry naming what was wrong and what changed.

The point is not that AgentScore got everything right. The point is that the iteration is visible. A reader who finds an old advisory on a package and a corrected scan on the live report page can see the gap and the correction note explaining it. They do not have to trust the system. They can read both versions and decide.

For anyone running continuous scanning at scale on a public surface, the lesson is: the loud direction (false positives) is easier to catch than the quiet direction (false negatives), the FN risk gets harder once you start tightening, and the only thing that compounds credibility through all of it is doing the corrections in public.

AgentScore continuously scans MCP packages on npm and publishes a public security record. Live data, advisories, and the full mitigator changelog are at agentscores.xyz.

Good abstractions are great when you are building software.

They are much less great when you are debugging production.

The reason is simple: abstraction hides details, and debugging often depends on the details you hoped to ignore.

In small codebases, this is barely noticeable. In real systems, especially with caches, async flows, optimistic UI, and multiple state owners, it becomes a serious problem.

The core issue

The more layers you add, the easier it is for the system to become “locally correct” and “globally wrong”.

For example:

• the frontend thinks the payment succeeded,
• the backend committed the transaction,
• the event was published,
• the cache still serves the old value,
• the UI shows stale data.

Every layer is doing something reasonable.

The problem is that they are not all talking about the same version of reality.

A simple example

Imagine this flow:

1. User clicks Retry payment
2. Frontend updates UI optimistically
3. API returns 200 OK
4. Database is updated
5. Event is sent to downstream systems
6. Redis still serves old state
7. UI refreshes from cache and shows stale data

This is the kind of bug that wastes hours.

Not because any single line of code is hard, but because the truth is spread across several places.

Example in code

Let’s say the frontend uses optimistic updates:

const onRetryPayment = async () => {
  setPaymentStatus("PAID");

  try {
    const response = await fetch("/api/payments/retry", {
      method: "POST",
    });

    if (!response.ok) {
      throw new Error("Retry failed");
    }
  } catch (error) {
    setPaymentStatus("FAILED");
  }
};

At first glance, this looks fine.

But now imagine:

• the API succeeds,
• the DB is updated,
• an event is emitted,
• a consumer deduplicates the event incorrectly,
• Redis still contains the old value,
• the UI re-renders from stale cache.

The bug is no longer in this function.

The bug is in the propagation path.

Why abstractions make this worse

Abstractions hide the exact mechanics that matter during incidents.

They hide things like:

• who owns the state,
• when the state changes,
• whether the update is synchronous or async,
• whether caches are invalidated,
• whether retries are safe,
• whether events can arrive out of order.

That is useful in normal development.

It is terrible during debugging.

Because when something is wrong, you do not need another clean interface. You need visibility.

Typical failure patterns

These are the patterns I see most often in real systems.

1. Stale read

The data was updated, but one layer still serves an old version.

// DB updated successfully
await db.payment.update({
  where: { id: paymentId },
  data: { status: "PAID" },
});

// Cache not invalidated

Result:

• DB = PAID
• cache = PENDING
• UI = PENDING

2. Lost update

Two writes happen close together, and one silently overwrites the other.

await updateProfile({ name: "Alex" });
await updateProfile({ name: "John" });

If the system uses last-write-wins without proper locking or versioning, the final state may not match user intent.

3. Ghost update

One layer changes, but another never receives the update.

dispatch(updateOrderStatus("PAID"));
// but query cache is never invalidated

The result is a UI that looks stuck even though the backend is correct.

4. Event reorder bug

Events arrive in a different order than they were produced.

// Event B processed before Event A
processEvent("payment_succeeded");
processEvent("payment_pending");

Now the final state may be wrong even if both handlers are valid.

The debugging trap

The trap is assuming this is a code bug.

Very often it is not.

It is a state ownership bug.

That means the real question is not:

• “Which function crashed?”

The real question is:

• “Which layer is the source of truth right now?”

If you cannot answer that clearly, debugging becomes guesswork.

A better way to think about it

Instead of thinking in terms of “where is the bug?”, think in terms of “where does state live?”

A useful checklist:

• Where is the canonical value stored?
• Which layer may cache it?
• Which layer may derive it?
• Which layer may overwrite it?
• Which layer may delay it?
• Which layer may retry it?

If the same value exists in five places, you now have five opportunities for disagreement.

Debugging strategy

When a bug crosses abstraction boundaries, I usually inspect it in this order:

Step 1: Check the source of truth

Confirm where the canonical data lives.

Step 2: Rebuild the timeline

Trace the state from user action to backend write to cache update to UI read.

Step 3: Check invalidation

If a cache exists, verify it is updated or cleared at the right moment.

Step 4: Check idempotency

If retries or events are involved, verify the operation can safely happen more than once.

Step 5: Check ordering

If events are async, verify the system does not depend on strict ordering unless it actually guarantees it.

When abstractions do help

This is not an anti-abstraction argument.

Good abstractions are still valuable when they:

• reduce search space,
• make ownership clear,
• keep state local,
• expose transitions explicitly.

For example, a small component with local state is easier to debug than three caches and two event consumers trying to keep the same value in sync.

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

This is easy to reason about because there is one owner of the state.

That is the difference.

What to do in real systems

If you want abstractions to stay helpful in production, make them observable.

That means:

• add logs at boundaries,
• use trace IDs,
• keep ownership explicit,
• invalidate caches intentionally,
• design retries to be safe,
• avoid hidden duplicated state.

A good abstraction should reduce complexity, not hide the mechanics that make incidents debuggable.

Final thought

The best abstractions are honest.

They do not pretend the system is simpler than it is. They make the system easier to understand without hiding where truth lives.

That is why debugging gets harder as systems grow: not because abstraction is bad, but because abstraction is often too successful at hiding the exact thing you need under pressure.

A field report on tracking coordinated inauthentic behavior through commit signatures, backdated git history, and an automation tool that left its process ID embedded in three README files.

This is Part 3 of an ongoing investigation. Part 1 documented the initial discovery — 8 accounts with Jaccard following-list similarity of 0.99+ across ~29,800 entries each, evading cross-follow detection entirely. Part 2 expanded the cluster to 9 accounts and attributed the generation pipeline to a specific GitHub identity: hajigur69.

This part covers an earlier operation by the same operator, running nine months before the follow botnet was provisioned. The hajigur69 co-author fingerprint is present in both. So is the fallback_ generator artifact. The infrastructure was already running.

It started with a string.

66867581+hajigur69

That number-plus-username combination kept appearing in Co-authored-by commit trailers across thousands of commits from dozens of different GitHub accounts. Not as an author. Not as a committer. Embedded in the trailer block, like a watermark — or a coordination mechanism the operator never rotated.

That string became the fingerprint for an entire network.

What I Was Looking At

The network — I’m calling it HAJINET — operates across six distinct layers:

1. Commit farming: Coordinated accounts mass-generate commits embedding the hajigur69 co-author signature to inflate contribution graphs
2. Repo spam: 400+ procedurally generated repositories with LLM-written READMEs targeting crypto/Web3 search terms
3. Fake engagement: Purchased stars from a third-party service to boost GitHub and Google search ranking
4. Follow spam: Mass-following (30,000+ on the primary account) to appear legitimate
5. SEO poisoning: Cloning the names of famous repos like system-design-primer and developer-roadmap
6. GitHub as persistence backend: Using a repository’s commit history as a synthetic activity signal and data persistence mechanism — with fabricated timestamps going back seven months before the account existed

By the time I was done, I had 24 accounts, 33 confirmed star-service bot accounts, a root commit SHA proving a 213-day timeline impossibility, and three README files containing an automation tool’s process ID that it forgot to strip before pushing.

Here’s how I found it.

The 24 accounts: the 9-account follow botnet cluster (canestein, hazexone, domcomit, kylehyne, jaderytm, vierystein, hanyvert, mariwatts, lynewinter) plus Lyne6666, uhsr, mohammadtzs, and 12 additional commit-farming accounts identified via the hajigur69 co-author signature. Four of the botnet cluster accounts — canestein, hazexone, domcomit, and kylehyne — appear in both this operation and the follow botnet documented in Parts 1 and 2. They are the same operator’s assets across both deployments.

The Commit Fingerprint

When the 66867581+hajigur69 string first appeared in search results, the volume was the tell. GitHub’s commit search API showed it across thousands of commits from a cluster of 22 accounts — canestein, hazexone, domcomit, kylehyne, and 18 others — all generating commits in a tight July–August 2025 window:

2025-07-08..2025-07-14 :  1,738 hits
2025-07-15..2025-07-21 :    701 hits
2025-07-22..2025-07-31 :    949 hits
2025-08-01..2025-08-15 :  7,194 hits  ← peak
2025-08-16..2025-08-31 :      0 hits  ← hard stop

The August 16 cliff edge is significant. That’s not a developer going on vacation. That’s consistent with an account action or a deliberate operator pivot.

The hajigur69 account’s GitHub ID is 66867581. That numeric ID embedded alongside the username in the co-author string is what made it searchable. Whoever set up the automation configured it once and never rotated the signature.

The Satellite Account

Following the commit graph led to Lyne6666, an account created May 3, 2025 with 163 public repositories — all created on July 9, 2025 at 18:55 UTC. Multiple commits in the same minute. I pulled the LICENSE SHA from a sample:

8aa26455d23acf904be3ed9dfb3a3efe3e49245a

Same SHA across all 163 repos. That’s not a coincidence — it’s a file copy from a template directory that never changed. Git hashes content, not filenames. Identical SHA means identical bytes, which means the same LICENSE was stamped into every repo from a single source.

The repo names followed a template: {Tech}{Testnet}{Function}{Suffix}. TPUTestnetSystemSolutionsNext. DAOTestnetAIKitPro. IoTTestnetPlatformLabsX. Every README had this in the install section:

pip install git+https://github.com/Lyne6666/{RepoName}.git

163 repos. 163 pip install vectors. No postinstall hooks confirmed yet, but the infrastructure is there.

The Primary Operator

The Lyne6666 repos had an email in the commit headers: [email protected]. That’s a private burner domain — one user, WHOIS privacy-shielded via Identity Digital. The account it led to, uhsr, was created July 10, 2025 — one day after Lyne6666‘s mass repo creation.

At the time of investigation: 237 public repos, 2,972 followers, 30,778 following.

That following-to-follower ratio — 10.4:1 — is a follow-spam pattern. Mass-follow enough accounts and some percentage follow back, which makes the account look organically connected to a real community.

uhsr‘s commit volume shows the operation’s activity profile in four numbers:

July 2025:       1,382 commits  (71% of all-time activity)
August 2025:       247 commits
September 2025:     21 commits
October 2025:       96 commits

71% of an account’s entire commit history in a single month. That’s not a developer. That’s a deployment window.

The Impossible Timeline

uhsr/AssetMarket was the most interesting repository. It contained a .Logs file with ~365 entries running from January 1, 2025 through December 31, 2025. Daily entries, format: Logs: YYYY-MM-DD <8charToken>.

The repo was created August 2, 2025.

curl -s "https://api.github.com/repos/uhsr/AssetMarket" | python3 -c "
import json,sys; r=json.load(sys.stdin)
print(r['created_at'])
"
# 2025-08-02T16:29:22Z

So I pulled the commit history and paginated back to the earliest entries. The root commit:

SHA:            4f8f47697eb89c8818820ca92348be01c4544878
Message:        Logs on 2025-01-01
Author date:    2025-01-01T14:47:47Z
Committer date: 2025-01-01T14:47:47Z
Author email:   [email protected]

Repo created:   2025-08-02T16:29:22Z

A commit dated January 1 in a repo that didn’t exist until August 2. That’s 213 days of fabricated git history.

The technique is worth noting: both GIT_AUTHOR_DATE and GIT_COMMITTER_DATE were overridden simultaneously. Naive backdating only sets the author date, leaving the committer date as the real push timestamp — a detectable mismatch. This operator knew that. They set both fields identically on every commit in the fabricated window. The .Logs file with its 8-character daily tokens appears synthetically generated rather than organically accumulated — consistent with a bulk scripted push using pre-generated identifiers, designed to make the contribution graph look like 7 months of continuous activity.

The repository is consistent with use as a synthetic activity signal and lightweight persistence backend, not legitimate version control.

The Tool That Left Its Name in the File

The high-value repositories — AssetMarket, SmartContract, DigitalWallet, TokenLab, BlockchainKit — all had longer, LLM-generated READMEs. While pulling the raw content of AssetMarket‘s README, I found this at the top:

<!-- fallback_AssetMarket_20250802163009_95172 -->

An HTML comment. Invisible on the rendered page. Accidentally left in by the generation script.

Breaking it down:

• fallback — the secondary template fired because the primary LLM generation path failed
• AssetMarket — the repo name variable
• 20250802163009 — generation timestamp: August 2, 2025, 16:30:09 UTC
• 95172 — process ID from the generation script

I searched the rest of uhsr‘s repos and found two more:

uhsr/SmartContract  → <!-- fallback_SmartContract_20250802162757_83653 -->
uhsr/TokenLab       → <!-- fallback_TokenLab_20250802161931_80263 -->

Three repos, same machine, 38-minute window:

16:19:31  TokenLab      PID 80263
16:27:57  SmartContract PID 83653
16:30:09  AssetMarket   PID 95172

The PID gaps are irregular — consistent with a script iterating a repo list with API calls and sleep intervals between each generation run, with OS background processes accounting for the PID jumps. The fallback label on all three means the primary LLM path failed or timed out on all three in sequence, and the static fallback template was substituted. That’s why every feature bullet in all three READMEs contains the identical filler string:

“Advanced implementation with optimized performance and comprehensive error handling”

That’s the placeholder text for a template field that had no content. The script pushed it anyway.

The Star Service

The high-star repos had suspiciously uniform engagement. AssetMarket had 83 stars. SmartContract had 50. DigitalWallet had 49. Zero forks across all of them except one, which led to mohammadtzs — more on that shortly.

I pulled the stargazer lists and cross-referenced:

AssetMarket ∩ DigitalWallet ∩ SmartContract = 33 accounts

33 accounts starred all three repos. That’s 67% of DigitalWallet‘s total star count. Organic discovery doesn’t produce that overlap. This overlap pattern is consistent with a shared purchased-engagement pool being reused across repos.

The July 11 batch — 83 repos created in a single day — showed the purchase tier structure directly:

★2: 64 repos  (77%)
★1: 19 repos  (23%)
★0:  0 repos

Zero repos with zero stars. Every single one got at least one. The distribution has no organic variance. It reads like a bulk order: “2 stars each, downgrade 19 to 1.”

The August 2 high-value repos got proportionally more investment: AssetMarket at 83, SmartContract at 50, BlockchainKit at 36. The star spend correlates exactly with the repos that have pip install vectors in their READMEs — the ones most likely to get actually installed by a developer who finds them in search results.

The cross-network link: Two accounts from the 33 — SAPH1TE and ahnshy — also appear in the stargazer lists for Lyne6666 repos. The uhsr cluster and the Lyne6666 cluster were deliberately siloed (no social graph overlap, different account creation dates, different repo naming patterns). But they used the same star purchase service. That vendor relationship is the infrastructure bridge between the two otherwise separate network segments.

mohammadtzs

The one fork of DigitalWallet came from mohammadtzs, whose bio reads “Ex-gamer turned full-time Web3 airdrop hunter.” Created March 2025, 506 public repos, 100 forks — all from accounts that no longer exist (deleted or banned). The fork names included alork1, alork2, alork3, alorki1 — the cluster’s {name}{number} account generation pattern.

And mohammadtzs appeared in the 33-account star service pool.

Not a victim who stumbled onto a fake repo. A participant in the same engagement ecosystem, likely forking cluster repos to build social graph signals for airdrop qualification while the cluster provides the fake stars that make the airdrop worthwhile.

The October Pivot

When the August ban wave hit, the activity dropped to near zero in September. October brought 96 commits — almost entirely from a single scripted run on October 20, 2025, between 05:04 and 05:19 UTC:

awesomepythonTech        → impersonates vinta/awesome-python
freeprogrammingbooksHub  → impersonates EbookFoundation/free-programming-books
publicapisAI             → impersonates public-apis/public-apis
codinginterviewuniversityTools → impersonates jwasham/coding-interview-university
developerroadmapLab      → impersonates kamranahmedse/developer-roadmap
systemdesignprimerCloud  → impersonates donnemartin/system-design-primer
buildyourownxTools       → impersonates codecrafters-io/build-your-own-x

Seven repos in 15 minutes, all named after repositories with 230,000–340,000 stars. None contain any actual content. The descriptions are raw template output — developerroadmapLab has "enterprise enterprise-grade" in its description, a doubled template token that made it through with no human review.

This is the operation’s final documented phase: when the commit farming network got disrupted, the operator pivoted to pure SEO poisoning — trying to capture search traffic from developers looking for the real repositories.

What This Is

The full picture:

A scripted infrastructure generates accounts, populates them with LLM-written repositories targeting crypto and Web3 search terms, purchases stars to boost their GitHub search ranking, and mass-follows accounts to build a fake social graph. The high-value repos have pip install vectors ready. The primary operator’s account carries 7 months of fabricated commit history to look established. And when the commit farming network gets disrupted, the operation pivots to SEO poisoning of the most-searched developer repositories on the platform.

The generator tool left its process ID in three README files. The star service reused the same 33 accounts across every repo. The co-author fingerprint never rotated. For a technically sophisticated operation, the operational security was consistently poor — but that’s often how these get found.

Disclosure

This report has been submitted in full to GitHub Trust & Safety with API-verifiable evidence including the root backdated commit SHA (4f8f47697eb89c8818820ca92348be01c4544878), the generator artifact URLs, the 33-account star service fingerprint, and the complete account list.

All data was retrieved via the GitHub REST API v3 with authenticated requests. No accounts were accessed beyond their public API data. No systems were compromised.

The accounts canestein, hazexone, domcomit, and kylehyne documented here also appear in the follow botnet cluster identified in Parts 1 and 2. This report and those reports cover the same operator across two separate deployments.

If you recognize any of these accounts or have seen the hajigur69 co-author string in your own repos’ commit histories, that’s the network’s fingerprint — and worth reporting.

Cursor has spent the last year moving from “AI coding assistant” into something much more ambitious: a vertically integrated agentic software engineering stack. Yesterday’s release of Composer 2.5 makes that direction impossible to ignore.

This is not just a faster autocomplete model. Cursor is explicitly optimizing for long-horizon coding agents that can plan, execute, recover from failures, and stay coherent across large multi-step engineering tasks.

The Problem It’s Solving

Most coding models still break the moment a task stops being local.

They can generate a React component, patch a bug, or refactor a function. But once the task becomes multi-file, infrastructure-heavy, or operationally ambiguous, the cracks show quickly. Context drifts. Tool calls fail. The model loops. Terminal sessions become chaotic. Long-running execution loses coherence.

That is the real bottleneck in agentic software engineering right now.

Cursor says Composer 2.5 was specifically trained to improve “long-horizon agentic tasks” and follow complex instructions more reliably. The company also claims substantial behavioral improvements around effort calibration, communication style, and execution consistency. (Cursor)

This matters because the next phase of AI coding is no longer about code generation quality alone. It is about whether agents can operate inside real engineering environments without constantly collapsing under state management and execution complexity.

How Composer 2.5 Actually Works

Under the hood, Composer 2.5 continues Cursor’s strategy from Composer 2: domain-specialized reinforcement learning for software engineering workflows.

Cursor’s technical report for Composer 2 describes a two-stage training pipeline:

1. Continued pretraining on a base model
2. Large-scale reinforcement learning inside real software engineering environments and agent harnesses (arXiv)

The important detail is not the benchmark number. It is the training environment.

Cursor is training models directly inside the same operational harness used by deployed coding agents — including terminals, tools, multi-step execution chains, and realistic repository interactions. That creates a feedback loop where the model is optimized for actual agent workflows instead of isolated benchmark prompts. (arXiv)

Composer 2.5 reportedly improves:

• Long-running task reliability
• Multi-step execution planning
• Instruction adherence
• Agent communication behavior
• Effort calibration during coding workflows (The Indian Express)

There is another important layer here: infrastructure economics.

Composer 2 originally gained attention because Cursor delivered strong coding performance at dramatically lower token costs than frontier proprietary models. Cursor positioned it as a cheaper alternative to systems from Anthropic and OpenAI. (Cursor)

That pricing advantage came with controversy.

After launch, developers discovered Composer 2 was built on top of Moonshot AI‘s open-weight Kimi K2.5 model. Cursor later acknowledged this publicly and admitted it should have disclosed the base model earlier. (Business Insider)

Composer 2.5 reportedly still builds on the same Kimi base checkpoint, but Cursor is increasingly differentiating through RL infrastructure, agent training environments, and deployment tooling rather than raw foundational pretraining. (The Indian Express)

That is a very different strategy from the “train everything from scratch” approach most frontier labs market publicly.

What Developers Are Actually Using It For

The interesting part about Cursor’s recent releases is that they increasingly resemble operational AI infrastructure rather than a standalone IDE.

Over the last few months, Cursor has launched:

• Cursor SDK for programmatic agents
• Cloud development environments for agents
• Bugbot autonomous debugging systems
• Multi-agent execution workflows
• Cursor 3, a broader agentic workspace layer (Cursor)

Composer 2.5 sits in the middle of that stack.

The target use case is no longer “help me write code faster.” It is:

• Autonomous repository maintenance
• Long-running refactors
• Infrastructure migration workflows
• Multi-step debugging
• Agent-managed terminal execution
• PR generation and validation
• Extended software tasks that may run for hours

That direction aligns closely with where the broader MCP and agentic ecosystem is heading.

The future competitive advantage is not just model intelligence. It is orchestration quality: tool reliability, memory handling, execution recovery, context persistence, and operational safety across long-running workflows.

This is exactly why infrastructure companies like Gentoro and MCP ecosystem players like Glama.ai matter increasingly in the stack. Models are becoming interchangeable faster than orchestration layers are.

Why This Is a Bigger Deal Than It Looks

Cursor is quietly proving something the broader AI market still underestimates:

Specialized agent training may matter more than raw frontier scale for real-world developer workflows.

Composer 2.5 is not trying to be a universal reasoning model. It is being optimized aggressively for software execution environments.

That shift has major implications.

The AI coding market is rapidly splitting into two layers:

• Foundation model providers
• Agent orchestration and execution platforms

Cursor appears to be betting the second layer becomes more defensible over time.

That also explains why the company is investing heavily in infrastructure. Reports indicate Cursor plans to train Composer 2.5 using xAI compute infrastructure with tens of thousands of GPUs. (Business Insider)

The strategic signal here is important:
AI coding is moving from “chatbot in an editor” toward persistent software agents operating inside full execution environments.

And once that happens, infrastructure quality becomes the actual moat.

Availability and Access

Composer 2.5 is now available through Cursor.

The release follows Cursor’s broader push into autonomous coding systems and arrives during intensifying competition from Claude Code, OpenAI, and other agentic developer tooling platforms. (WIRED)

The bigger story is not whether Composer 2.5 wins a benchmark cycle. It is that Cursor is steadily building an operational stack for autonomous software engineering.

The IDE war is turning into an agent infrastructure war.

Follow for more coverage on MCP, agentic AI, and AI infrastructure.

Most people ask:

“What’s the best AI coding tool?”

After building 4 AI-assisted projects, I realized the better question is:

“Which tool fits each stage of the workflow?”

My current workflow:

• ChatGPT → ideas and prompts
• Windsurf → rough project structure
• Codex → fix and refactor logic
• Cursor → production polish

Using this workflow, I built:

1. Parent-child emotional connection app
2. English learning platform
3. AI video project
4. Affiliate marketing system

Biggest lesson:

AI doesn’t magically replace developers.

It reduces friction between:
idea → prototype → working product.

That’s where the real leverage is.

For years, Microsoft’s open source strategy was mostly about cloud adoption and developer ecosystems. At Open Source Summit North America 2026, the company made something much bigger clear: it now sees open protocols and agent infrastructure as the next foundational layer of computing.

And buried inside that announcement was the real signal for the MCP ecosystem.

The Problem It’s Solving

Right now, most AI agents are still trapped inside fragmented execution environments.

Every framework has its own tooling model. Every cloud vendor has its own orchestration stack. Tool access, memory handling, governance, and runtime execution are all implemented differently depending on the platform. That fragmentation becomes a serious problem once agents move from demos into production infrastructure.

Microsoft’s latest messaging is essentially acknowledging that agentic systems need the equivalent of what Kubernetes became for containers: portable infrastructure primitives and open interoperability standards. ([Microsoft Open Source][1])

That is where MCP starts becoming strategically important.

Model Context Protocol was initially framed as a standardized interface for connecting models to tools and external systems. But the ecosystem around it has evolved rapidly. MCP is increasingly becoming a shared interoperability layer for agent execution environments, tool routing, UI delivery, and cross-platform orchestration. ([Wikipedia][2])

Microsoft’s Open Source Summit announcement strongly suggests the company understands that shift.

How Microsoft’s Open Agentic Stack Actually Works

In its official summit post, Microsoft explicitly described its vision around “frameworks, protocols, and governance for AI agents” and repeatedly emphasized the need for agents to operate “across frameworks, clouds, languages, and runtimes.” ([Microsoft Open Source][1])

That wording matters.

The company is no longer talking about isolated copilots. It is talking about infrastructure portability.

Microsoft’s announcement centered around several major layers:

• Azure Linux 4.0
• Azure Container Linux
• Open governance tooling
• Secure software supply chain infrastructure
• Open agentic system interoperability ([SDxCentral][3])

The Linux layer is especially important here.

Microsoft says Azure Linux 4.0 is being positioned as a hardened operating system foundation for cloud-native and AI-native workloads. The company also confirmed that Linux infrastructure now underpins large parts of Azure’s AI stack, including services tied to GitHub, Microsoft 365, and ChatGPT-scale deployments. ([Cloud Native Now][4])

That changes the MCP conversation significantly.

MCP servers do not exist in isolation. Real-world deployment requires:

• Sandboxed execution
• Tool governance
• Authentication layers
• Runtime isolation
• Observability
• Secure software supply chains
• Container orchestration
• Cross-agent communication

In other words, MCP adoption eventually becomes an infrastructure problem, not just a protocol problem.

Microsoft’s summit positioning suggests the company increasingly sees agent interoperability and runtime portability as core platform primitives — similar to how Kubernetes standardized container orchestration a decade ago.

What Developers Are Actually Building With MCP

The MCP ecosystem has quietly moved far beyond simple tool calling.

Developers are now using MCP to build:

• Multi-agent orchestration systems
• Secure enterprise tool gateways
• Agent memory layers
• Remote execution environments
• Interactive AI application interfaces
• Cross-model tool portability
• Agent observability pipelines

That evolution is happening fast across the open ecosystem.

The Agentic AI Foundation recently positioned MCP as a key interoperability layer for “secure, scalable agentic AI systems” operating across tools, models, and platforms. ([Linux Foundation][5])

At the same time, infrastructure companies are racing to operationalize the stack around it.

Platforms like Glama.ai are increasingly focused on MCP gateway quality, discoverability, and secure tool integration. Companies like Gentoro are working on orchestration and infrastructure layers for enterprise-grade agent systems.

This is the important shift:
the protocol itself is becoming less valuable than the operational ecosystem forming around it.

And Microsoft appears to be positioning Azure directly underneath that future stack.

Why This Is a Bigger Deal Than It Looks

The most important part of Microsoft’s announcement was not Linux.

It was the company openly framing agentic AI as an open systems problem rather than a proprietary model problem.

That is a major strategic distinction.

The AI industry spent the last two years competing almost entirely on model intelligence. But production agent systems introduce a completely different bottleneck:

• interoperability
• execution reliability
• governance
• runtime security
• infrastructure portability
• software supply chain trust

Those are open infrastructure problems.

That is also why Open Source Summit North America 2026 heavily centered discussions around AI infrastructure, supply chain security, embedded systems, and agentic AI on the same stage. ([Cloud Native Now][6])

The ecosystem is converging around a new reality:
agents are becoming distributed systems.

And distributed systems historically standardize around open protocols faster than proprietary interfaces.

That creates a very favorable environment for MCP.

Availability and Access

Microsoft’s announcements around Azure Linux 4.0 and Azure Container Linux were unveiled during Open Source Summit North America 2026, with broader rollout activity expected around Microsoft Build. ([SDxCentral][3])

The more important takeaway is strategic:
Microsoft is increasingly treating agent infrastructure as a first-class cloud layer.

And once cloud vendors start organizing around open agent interoperability, MCP stops looking like a niche protocol and starts looking like foundational infrastructure.

Follow for more coverage on MCP, agentic AI, and AI infrastructure.