A quiet week on the calendar, but not in the inbox. Two stories worth your attention: one about secrets you may have already exposed without knowing it, and one about what happens to infrastructure when agents start doing the work humans used to do. Plus a Developer Spotlight on an engineer who writes about reliability the honest way — by showing you exactly where things break.
The "don't ask again" click that put 2,539 secrets on GitHub
Here's how it happens. You're working in Claude Code, you tell it to run a command that includes a password or API key, and you click "don't ask again" to skip future approval prompts for that command type. Claude Code saves that command — secret and all — to .claude/settings.local.json. The file is meant to stay local. But if it ends up committed to Git, every secret inside it is now public.
Researchers at Apiiro went looking for exactly that file across public GitHub repositories. They found real secrets in about 1.1% of the 104,185 copies they scanned. When they expanded the search to Git history, shared settings files, and saved agent transcripts, the count rose to 2,539 distinct secrets across 1,994 repositories — database passwords, Supabase keys and tokens, SSH credentials.
A few things make this harder to catch than it looks. Claude Code adds the file to a developer's global Git excludes automatically, but that setting doesn't carry over to teammates or to files already tracked. Standard secret scanners — Gitleaks and TruffleHog — missed about one in five affected files, because they're built to find provider key patterns, not passwords embedded inside shell commands. And deleting the file isn't enough: historical versions and forks still hold the credentials.
This isn't the first time it's surfaced. A bug report from August 2025 described the same behavior. Check Point found similar files in public npm packages in April. It keeps happening because the gap between "this feels local" and "this is actually in version history" is easy to miss when you're moving fast.
The action list is short. Rotate any exposed credentials first — before anything else. Search your GitHub organization and its full history for .claude/settings.local.json. Untrack the local file and add it to .gitignore. Keep literal secrets out of commands by using environment variables instead. And if your team is running agents that write config files, add secret detection to that workflow now rather than after the next scan.
Read more
OpenAI rebuilt Git — and nobody had to change a command
Coding agents nearly broke OpenAI's own source control. As Codex multiplied branches, pushes, and fetches across the monorepo, the old server couldn't keep up. Starting around the end of 2025, pushes slowed, merges failed, and reliability at times dropped below 90%.
OpenAI didn't replace Git. It rebuilt the backend behind it. The new system, Pando, now handles all development in the monorepo. Engineers and agents still run ordinary git push and git fetch commands. Nothing changed on their end.
The core problem was how the old server handled consistency. A conventional Git server treats the repository as one unit, so pushes to unrelated branches can queue behind each other. Pando coordinates each branch independently — two agents pushing to different branches never contend. A standard Git server also advertises every branch on every connection; with millions of branches, that list alone becomes heavy. Pando advertises only a designated trunk branch by default.
The results OpenAI reports from its own environment: median push latency fell about 80%. Pando moves nearly a petabyte of Git data daily using a handful of CPU cores. In its peak hour, it served more than 57 TB of packfiles, with over 99% coming from local disk cache. OpenAI says Codex helped build Pando in about 10 weeks — one engineer designed the core architecture, teams of agents implemented it.
Pando itself stays internal for now, though OpenAI says it's exploring ways to share the technology. Some packfile improvements are already merged upstream into Git.
The lesson for everyone else isn't to build a custom backend. It's to notice where the pressure appeared: not Git itself, but a service sized for the assumption that people push code a few times a day. Self-hosted Git servers, CI runners, artifact stores, and anything that clones on every push share that assumption. If you're running agents in parallel worktrees or CI, start tracking fetch latency and push failure rates now. Those numbers will tell you where your next bottleneck is before it shows up as a stalled merge queue.
Read more
Developer Spotlight this week
Sudhanshu Thakur is a software engineer and technical lead based in Noida, India, with more than 12 years in backend and distributed systems — Java, Spring Boot, Kafka, Kubernetes, and cloud-native patterns across AWS and Azure. He's been writing on Coder Legion since October, and his articles are worth reading because they show failure in progress, not failure cleaned up for a postmortem.
His Kafka piece starts with a learning project and a code review he did on himself. The setup: save an order to the database, then publish an event to Kafka as a separate step. A crash between the two means the customer sees a success confirmation and downstream systems never hear about the order. His fix — a transactional outbox with a relay, at-least-once delivery, and consumer deduplication — is straightforward once you see the gap, but most tutorials skip the gap entirely. He found it in his own code, and he wrote about it plainly.
The banking articles work the same way. He writes about migrating legacy SAS reports into a Salesforce workflow, and the whole piece is built around one principle: migrate the decision, not the screen. And his load-testing piece on report APIs is a good corrective to anyone who's shipped after a green JMeter run — averages hide problems, and one frequently-used report being unusable is invisible if you're only looking at overall p95.
Lately he's been pointing that experience at AI agents and MCP. The questions he brings from distributed systems — what does the system do when this step fails, and how does it know the difference between "no data" and "source unavailable" — turn out to be exactly the right questions to ask about agents too.
Follow Sudhanshu on Coder Legion
Note for Tom: Swap in one or two direct quotes from the interview before publishing — especially anything he said about moving from backend reliability work into AI agents, or his take on why engineers don't write about near-misses. His voice in the articles is direct and self-aware, so a quote in that register will land well here.
The two stories this week connect in an uncomfortable way. Agents are writing config files that hold secrets. Agents are pushing code at volumes that break infrastructure sized for humans. The tools are genuinely useful — that's not in question. But the operational assumptions underneath them haven't caught up. The teams that find out from an Apiiro scan or a 90% reliability drop are the ones who didn't track the signals earlier.
A lot of embargoes break next week. See you then.
Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.