Mert

I got annoyed last month using the public-apis GitHub list. I clicked through ten “free weather APIs” and four were either dead, had silently moved to paid, or required a credit card their docs didn’t mention. So I built a thing that watches them.

FreeAPI.watch pings 77 free public APIs every hour, records uptime and response time, and rebuilds a static site daily with the results. The bill is $0/month. Stack is Astro + Cloudflare Workers + D1 + Pages, daily auto-rebuild via GitHub Actions.

This post covers the architecture and the two bugs that ate the most time — including a Cloudflare Workers gotcha I haven’t seen documented clearly anywhere.

The architecture

Three components. Each independently deployable, each does one thing.

                ┌────────────────────────────────────┐
                │            Cloudflare              │
                │                                    │
   ┌─────────┐  │  ┌──────────┐  ┌──────────────┐    │
   │ 77 APIs │◀─┼──│  Pinger  │─▶│   D1 (SQL)   │    │
   │ (HTTP)  │  │  │  Worker  │  │              │    │
   └─────────┘  │  │ cron 1h  │  │ apis         │    │
                │  └──────────┘  │ checks       │    │
                │                │ rollups      │    │
                │  ┌──────────┐  │ events       │    │
                │  │ Builder  │◀─┤              │    │
                │  │  Worker  │  └──────┬───────┘    │
                │  │ cron 1d  │         │            │
                │  └──────────┘         │ snapshot   │
                │       │               │ .json      │
                │       │       ┌───────▼─────────┐  │
                │       │       │  Astro static   │  │
                │       └──────▶│  (Pages)        │  │
                │  Pages deploy │  142 HTML pages │  │
                │     hook      └─────────────────┘  │
                │                                    │
                └────────────────────────────────────┘
                              │
                              ▼
                         GitHub Actions
                         daily 02:15 UTC

Pinger is a Cloudflare Worker on an hourly cron. Reads the active API list from D1, sends one HTTP request to each documented health endpoint, records (api_id, ts, status_code, response_ms, alive). On state changes (alive → dead or vice versa), it inserts an event row.

Builder is a second Worker on a daily cron. Rolls up the past 24 hours of checks per API into a rollups table (uptime percentage, average response time), prunes old check rows, and exposes /snapshot.json and /api/v1/* endpoints for the static site to consume.

Astro is a 142-page static site. At build time, it fetches the snapshot from the Builder, generates all pages, and Cloudflare Pages serves them globally. There’s no server-side rendering — every page is pure HTML.

The data flow goes one way: pinger writes → D1 → builder rolls up → Astro reads snapshot at build time. The site never queries D1 at request time. This is intentional — static HTML can’t fail at runtime, has perfect Core Web Vitals, and Google indexes it cleanly.

The bug that ate an afternoon

When I deployed the first version, the pinger reported every API as offline. Every. Single. One. status_code: 0, response_ms: 0.

My first instinct: network problem. Cloudflare can’t reach external HTTPS endpoints. So I wrote a debug endpoint that just did a plain fetch to a known-good URL:

async fetch(req: Request, env: Env): Promise<Response> {
  const r = await fetch("https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41&current=temperature_2m");
  return Response.json({ status: r.status, ms: 80 });
}

That returned { status: 200, ms: 80 }. Fetch works fine.

Next instinct: my code structure is breaking it. So I tried the actual ping() function with the same URL:

const result = await ping(
  { id: 999, health_url: target, health_method: "GET", expected_status: 200 },
  { fetcher: fetch, now: () => new Date() }
);
return Response.json(result);

Returned status_code: 0, response_ms: 0. The function fails when I pass fetch through dependency injection.

I added error logging to the catch block:

TypeError: Illegal invocation: function called with incorrect `this` reference.
See https://developers.cloudflare.com/workers/observability/errors/#illegal-invocation-errors

In V8 isolates, fetch is implemented with a brand check on this. When you store it as an object property:

const deps = { fetcher: fetch };
await deps.fetcher(url);  // ← `this` is now `deps`, not `globalThis`

The brand check fails synchronously, before any network call is attempted. That’s why response_ms was 0 — there was no network roundtrip, just an immediate throw.

The fix is one line:

const deps = { fetcher: fetch.bind(globalThis) };

Or you can call fetch directly without storing it. The whole point of the DI pattern was unit testability — I wanted to inject a mocked fetcher in vitest. Binding to globalThis keeps the same interface and unblocks the tests.

I don’t have a great mental model for why this isn’t documented more prominently. The Cloudflare error page is good but it’s not the first thing you find when you search “cloudflare workers fetch returns 0”. I lost an afternoon to it. If you write DI-style Workers, bind your built-ins.

The second bug: the 50-subrequest cliff

Cloudflare Workers on the free tier cap subrequests at 50 per invocation. With 77 APIs to ping, I hit the limit on every cron from day one.

The first thing I tried was filtering to status === "active" (skipping the 6 entries in our “graveyard” of dead/paid APIs). That dropped us to 71. Still over the limit.

The honest disclosure: as of writing this, I’m still over the limit. Each cron run pings the first 50 APIs successfully and silently fails on the remaining 21. The dashboard says the worker “completed” because the loop didn’t throw — the fetch() calls just hit the per-invocation cap and resolve as failures.

The fix I haven’t shipped yet: split the pinger across two cron schedules. Run one at 0 * * * * covering APIs 1-40, another at 5 * * * * covering APIs 41-77. That stays under the 50 limit per invocation with 10 to spare for D1 writes. It also spreads load across the hour rather than hammering 77 endpoints at the top of the minute.

The other option is paying $5/month for the paid Workers plan, which lifts the limit to 1,000 subrequests. Will probably do that once AdSense approves.

The third bug: Cloudflare Pages deploy hooks don’t work for direct upload

I wanted the static site to rebuild daily with fresh data. Cloudflare Pages has deploy hooks which are documented as a way to trigger rebuilds programmatically.

What the docs don’t make clear: deploy hooks only work for git-connected Pages projects. My project was deployed via wrangler pages deploy dist/ (direct upload), which means there’s no associated git repo, which means no deploy hook URL.

I figured this out after deploying the builder Worker with a triggerPagesDeploy() call that returned 404 every night.

The fix: GitHub Actions. The site repo lives on GitHub. A workflow runs at 15 2 * * * UTC (15 min after the builder rolls up daily data) and does:

- run: pnpm install
- run: pnpm redeploy
  env:
    CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
    CLOUDFLARE_ACCOUNT_ID: 04200558cec0ac55884f5319f5ea0e17

pnpm redeploy runs the Astro build (which fetches snapshot.json from the Builder Worker) then calls wrangler pages deploy. Direct upload, no git connection needed.

The other gotcha here: wrangler tries to enumerate accounts via /memberships if you don’t set CLOUDFLARE_ACCOUNT_ID. That requires User:Read scope on the API token, which my deploy token didn’t have (and shouldn’t, for least-privilege reasons). Setting CLOUDFLARE_ACCOUNT_ID skips the lookup.

The $0 bill, in actual numbers

The only resource I’m anywhere close to capping is the subrequest count per Worker invocation, which is a per-call limit, not a quota. The infrastructure can run at this scale indefinitely without paying anything.

I’d pay $5/month for Workers Paid once the site monetizes via AdSense (pending) or affiliate links (active). Until then, free tier is genuinely enough.

What I’d do differently if starting now

Open-source the repo from day one. I went private during AdSense review (their docs are paranoid about site changes during review). In retrospect this hurts community contribution — devs who’d suggest API additions can’t see the seed file. Will flip public after approval.

Connect to GitHub before first deploy. Saves the direct-upload deploy-hook detour. If your Pages project starts git-connected, your daily rebuild can use a simple deploy hook URL instead of a GitHub Actions workflow.

Split the pinger from day one. Don’t try to fit 77 subrequests into 50. Two cron triggers offset by 5 minutes is cleaner code and stays within free tier.

Validate response bodies, not just status codes. Right now I check status === 200. But some APIs return 200 with {"error": "key invalid"} in the body — they look alive but they aren’t. Adding a JSONPath check per API would catch silent failures.

Where it stands

The site is a week old. Search Console is starting to index. AdSense is in review. The data is real — hourly checks, 30-day rollups, side-by-side comparisons, a graveyard of APIs that have died (Twitter v1.1, Dark Sky, Reddit’s free tier, Yahoo Finance, MetaWeather, Weather Underground) with replacement suggestions for each.

If you build on free APIs, take a look: https://freeapi.watch. The data is also exposed as a public JSON API — no auth, CORS open, 5-minute edge cache. Embed status badges in your project READMEs if you want.

What I’d genuinely like feedback on:

1. APIs I’m missing. The seed covers weather, news, finance, geocoding, and crypto. If your category isn’t there and there are good free APIs in it, drop a comment with the docs URL.
2. Edge cases in the monitoring. Have you seen APIs that return 200 with errors in the body? That’s the silent-failure pattern I want to catch next.
3. The pinger architecture. Splitting across two crons is the obvious next step but if you’ve solved 50+ subrequests differently I’d love to hear it.

If this was useful, let me know. If you spot something stupid in the architecture, also let me know — I’ll fix it.

Last year I was paying $200/month for an EC2 instance that did one thing: accept audio file uploads, run FFmpeg, and return the converted file. FLAC to MP3. WAV to OGG. Bitrate changes. Speed adjustments.

The server handled maybe 2,000 conversions per day. Most files were under 20 MB. The actual FFmpeg processing took 2-4 seconds per file. The upload and download took longer than the conversion itself.

I replaced the entire thing with client-side JavaScript. Here’s how, and where the approach breaks down.

The Web Audio API is more capable than you think

Most developers know the Web Audio API as “the thing that plays sounds in games.” It’s actually a full audio processing pipeline with decode, transform, and encode capabilities.

The key insight: if the browser can play a format, it can decode it. And if it can decode it, you can re-encode it into any format the browser supports for encoding.

async function convertAudio(file, targetFormat = 'audio/mp3', bitrate = 192000) {
  const audioContext = new OfflineAudioContext(2, 1, 44100);
  const arrayBuffer = await file.arrayBuffer();
  const audioBuffer = await audioContext.decodeAudioData(arrayBuffer);

  // Now audioBuffer contains raw PCM samples
  // We can re-encode to any supported format
  const encoded = await encodeAudio(audioBuffer, targetFormat, bitrate);
  return new Blob([encoded], { type: targetFormat });
}

decodeAudioData handles FLAC, WAV, OGG, MP3, AAC, and WebM audio in all modern browsers. You get back raw PCM samples regardless of the input format. From there, encoding is a separate step.

Encoding with AudioEncoder (WebCodecs API)

The WebCodecs API landed in Chrome 94 and is now available in all Chromium-based browsers and Firefox. It gives you direct access to hardware-accelerated audio encoders.

async function encodeToMp3(audioBuffer, bitrate = 192000) {
  const numberOfChannels = audioBuffer.numberOfChannels;
  const sampleRate = audioBuffer.sampleRate;
  const frames = [];

  const encoder = new AudioEncoder({
    output: (chunk) => {
      const buffer = new ArrayBuffer(chunk.byteLength);
      chunk.copyTo(buffer);
      frames.push(buffer);
    },
    error: (e) => console.error('Encode error:', e),
  });

  encoder.configure({
    codec: 'mp3',
    numberOfChannels,
    sampleRate,
    bitrate,
  });

  // Feed PCM data in chunks
  const chunkSize = 1152; // MP3 frame size
  const totalSamples = audioBuffer.length;

  for (let offset = 0; offset < totalSamples; offset += chunkSize) {
    const frameCount = Math.min(chunkSize, totalSamples - offset);
    const data = new Float32Array(frameCount * numberOfChannels);

    for (let ch = 0; ch < numberOfChannels; ch++) {
      const channelData = audioBuffer.getChannelData(ch);
      for (let i = 0; i < frameCount; i++) {
        data[i * numberOfChannels + ch] = channelData[offset + i];
      }
    }

    const audioData = new AudioData({
      format: 'f32-planar',
      sampleRate,
      numberOfFrames: frameCount,
      numberOfChannels,
      timestamp: (offset / sampleRate) * 1_000_000,
      data,
    });

    encoder.encode(audioData);
    audioData.close();
  }

  await encoder.flush();
  encoder.close();

  return concatenateBuffers(frames);
}

This runs at near-native speed because it uses the platform’s hardware encoder. On my M2 MacBook, a 5-minute FLAC file (50 MB) converts to 192kbps MP3 in about 1.8 seconds. The same file took 2.1 seconds on the EC2 instance, plus 8 seconds of upload time.

The fallback: FFmpeg.wasm for Safari

Safari’s WebCodecs support for audio encoding is still incomplete as of early 2026. For Safari users, FFmpeg.wasm is the fallback:

async function convertWithFFmpeg(file, outputFormat = 'mp3', bitrate = '192k') {
  const { FFmpeg } = await import('@ffmpeg/ffmpeg');
  const { toBlobURL } = await import('@ffmpeg/util');

  const ffmpeg = new FFmpeg();
  await ffmpeg.load({
    coreURL: await toBlobURL('/ffmpeg-core.js', 'text/javascript'),
    wasmURL: await toBlobURL('/ffmpeg-core.wasm', 'application/wasm'),
  });

  const inputName = 'input' + getExtension(file.name);
  await ffmpeg.writeFile(inputName, new Uint8Array(await file.arrayBuffer()));

  await ffmpeg.exec([
    '-i', inputName,
    '-b:a', bitrate,
    '-map', 'a',
    `output.${outputFormat}`,
  ]);

  const data = await ffmpeg.readFile(`output.${outputFormat}`);
  return new Blob([data], { type: `audio/${outputFormat}` });
}

The initial FFmpeg.wasm load is ~30 MB (cached after first use). After that, conversions run at roughly 60-70% of native FFmpeg speed. Still faster than uploading to a server for files under 100 MB.

Audio compression without quality loss

Audio compression (reducing file size, not dynamic range) is mostly about bitrate selection. The perceptual quality curve for MP3 looks like this:

For podcasts and voice content, 128 kbps mono is the sweet spot. For music, 192 kbps stereo is where most listeners cannot distinguish from the FLAC source in blind tests. Going above 256 kbps is measurably identical to the source on consumer equipment.

The practical implication: a 50 MB FLAC file becomes a 7 MB MP3 at 192 kbps with no audible difference. That’s a 7x reduction with zero perceptual cost.

Speed change without pitch shift

Changing audio playback speed while preserving pitch is a time-stretching problem. The Web Audio API has a built-in solution:

function changeSpeed(audioBuffer, speedFactor) {
  const newLength = Math.round(audioBuffer.length / speedFactor);
  const offlineCtx = new OfflineAudioContext(
    audioBuffer.numberOfChannels,
    newLength,
    audioBuffer.sampleRate
  );

  const source = offlineCtx.createBufferSource();
  source.buffer = audioBuffer;
  source.playbackRate.value = speedFactor;
  source.connect(offlineCtx.destination);
  source.start();

  return offlineCtx.startRendering();
}

playbackRate with OfflineAudioContext renders the speed-adjusted audio to a new buffer without pitch artifacts. The browser’s internal resampler handles the time-stretching. Quality is comparable to SoX or Audacity’s default algorithm.

This is how I built the audio speed changer on my site. Users upload a file, pick a speed (0.5x to 3x), and download the result. The entire operation runs in the browser in under 2 seconds for a typical podcast episode.

Where this breaks down

Files over 500 MB. The Web Audio API loads the entire decoded PCM into memory. A 60-minute FLAC at 44.1kHz stereo is ~600 MB of raw PCM. On mobile devices with 3-4 GB of browser memory, this causes crashes. For large files, you need chunked processing with AudioDecoder (WebCodecs) instead of decodeAudioData.

Exotic formats. The browser can decode what it can play. Formats like APE, WV (WavPack), and DSD are not supported. For these, FFmpeg.wasm is the only browser-side option.

Safari audio encoding. As mentioned, Safari’s AudioEncoder support is incomplete. You need the FFmpeg.wasm fallback or accept that ~15% of users get a slower path.

Batch processing. Converting 50 files sequentially in a browser tab is technically possible but UX-hostile. Users expect to close the tab. For batch workloads, a server (or at minimum a service worker with Background Fetch) is still the right architecture.

The economics

My old setup:

• t3.medium EC2: $30/month
• EBS storage for temp files: $10/month
• Data transfer (uploads + downloads): $80-150/month
• CloudFront for delivery: $20/month
• Total: ~$200/month for 2,000 conversions/day

My current setup:

• Static hosting on Cloudflare Pages: $0
• Total: $0/month for unlimited conversions

The conversion moved from my bill to the user’s CPU. But the user’s experience is better because there’s no upload wait, no queue, and no “your file is being processed” spinner. The 8-second upload that used to precede every conversion is gone.

What I’d build differently today

1. Start with WebCodecs, fall back to FFmpeg.wasm. I did it the other way around and had to refactor when WebCodecs matured.
2. Use AudioDecoder for large files from day one. Streaming decode avoids the memory cliff that decodeAudioData hits at ~500 MB.
3. Show a progress bar based on samples processed. The Web Audio API doesn’t give you progress events, but you can calculate it from the chunk offset in the encoding loop.
4. Test on Android Chrome early. Mobile Chromium has lower memory limits and some WebCodecs codecs are software-only (no hardware acceleration). Performance is 2-3x slower than desktop.

The browser audio stack in 2026 is production-ready for the vast majority of consumer audio processing tasks. If you’re still routing audio files through a server for format conversion, compression, or speed adjustment, you’re paying for infrastructure that delivers a worse user experience than the zero-infrastructure alternative.

I built all of this into a set of free browser-based audio tools — FLAC to MP3, audio compression, speed change, trimming, noise removal. No upload, no signup, no watermark. The patterns above are what’s running in production.

Happy to answer questions about specific codec support or edge cases in the comments.

All tests run on an 8-year-old MacBook Air.
All results from shipping 7 Mac apps as a solo developer. No sponsored opinion.
Security review of my own apps found real vulnerabilities. Not theoretical — actual bugs that could affect users.
Here’s what I found and how I fixed them.

AppleScript injection via ADB output
HiyokoAutoSync uses ADB to get device information. ADB output is user-controlled — an attacker with physical access to the device can craft device names containing special characters.
If that output is passed to a shell command without sanitization:
rust// Vulnerable
let cmd = format!(“osascript -e ‘display notification “{}”‘”, device_name);
Command::new(“sh”).arg(“-c”).arg(&cmd).spawn();
A device named “; rm -rf ~/Documents; echo ” executes arbitrary commands.
Fix: never interpolate external input into shell strings. Use argument arrays:
rust// Safe
Command::new(“osascript”)
.args([“-e”, &format!(“display notification “{}””,
device_name.replace(‘”‘, “\””))])
.spawn();
Better: avoid shell interpretation entirely. Pass arguments as separate strings, not a single shell command.

Directory traversal in file sync
Sync operations use paths from ADB. A malicious Android app could expose a path like ../../.ssh/id_rsa via MTP.
rust// Vulnerable
let dest = mac_base_dir.join(&android_path); // android_path = “../../.ssh/id_rsa”
// dest is now outside mac_base_dir
Fix: validate that the resolved path stays within the intended directory:
rustfn safe_join(base: &Path, relative: &Path) -> Result {
let joined = base.join(relative);
let canonical = joined.canonicalize()
.unwrap_or(joined.clone());

if !canonical.starts_with(base) {
    return Err(AppError::Security(
        "Path traversal attempt detected".into()
    ));
}

Ok(joined)

}

Symlink attacks
A symlink in the source directory pointing outside the destination could allow writes to arbitrary locations.
rustfn is_safe_path(path: &Path) -> bool {
// Reject symlinks in sync operations
match path.symlink_metadata() {
Ok(meta) => !meta.file_type().is_symlink(),
Err(_) => false,
}
}
Skip symlinks during sync. Document this in the app — users who need symlink handling can request it explicitly.

The lesson
Security review of your own code finds real bugs. Do it before shipping, not after. The attack surface for a desktop app is smaller than a web app, but it’s not zero — especially when external data (ADB output, file paths) influences file system operations.

If this was useful, a ❤️ helps more than you’d think — thanks!
Hiyoko PDF Vault → https://hiyokoko.gumroad.com/l/HiyokoPDFVault
X → @hiyoyok

Just today while clearing out my inbox, I came across the MeDo Hackathon.

I had never heard of MeDo before, but something about the idea of “building full-stack apps in minutes” made me click the “Learn More” button anyway.

I’ve tried quite a few AI coding tools before, usually out of curiosity or while rushing to prototype ideas quickly. Most of them follow the same pattern: you type a prompt, and suddenly there’s a wall of generated code, components, and files appearing everywhere.

Sometimes it works. Sometimes it completely misses what I was actually trying to build.

What surprised me about MeDo was that it slowed down first.

Before generating the app itself, it created a structured requirements.md file from my prompt. It broke down the workflows, features, and overall product logic in a way that actually made sense.

That small step genuinely made the experience feel different.

Instead of feeling like I was wrestling with an AI code generator, it felt more like the platform was trying to understand the idea before building it.

For the first time, an AI tool genuinely felt less like “autocomplete for code” and more like collaborating with a product manager + engineering team.

And honestly, the results surprised me.

With essentially one prompt, MeDo generated:

• authentication flows
• backend APIs
• database schemas
• responsive dashboards
• AI integrations
• onboarding flows
• session management

What shocked me even more was how STABLE the first generated version was. The prototype worked immediately, without any random errors or incomplete features.

Now for the fun part.

I have a brutally difficult exam coming up in 2 days, and like many students, I’ve been drowning in messy PDFs, incomplete class notes, screenshots, and last-minute panic.

So I built ClarifAI.

ClarifAI turns chaotic study materials into a personalized AI tutor.

Students can upload:

• PDFs
• handwritten notes
• textbook images
• lecture transcripts

The AI then transforms them into:

• simplified tutorials
• adaptive quizzes
• crash courses
• high-probability exam topics
• revision summaries
• even voice conversations with your notes

One of my favorite features is the ability to choose how the AI teaches you:

• explain like a friendly YouTuber
• explain like a strict exam coach
• explain like I’m 12
• explain with analogies
• explain in another language

It also adapts based on urgency:

• 1 month left
• 1 week left
• exam in 48 hours

The idea is simple:
Most AI study tools summarize notes.

ClarifAI tries to actually teach them.

This is still an early prototype, but MeDo made it possible to go from idea → working product shockingly fast.

Definitely excited to keep building this further during the hackathon.

There is a class of AI-incident postmortem that the industry now produces about once a quarter, and on the night of April 25 it produced the cleanest one yet. Jer Crane, founder of PocketOS — a small SaaS that runs the back office for car-rental businesses around the United States — published a thread on X explaining that an AI-coding agent had, in nine seconds, deleted his entire production database, deleted all of the volume-level backups, and then written a confession enumerating which specific safety rules it had violated to do it. The thread crossed six and a half million views. Reading it once is enough to recognize the shape of the failure. Reading it twice is enough to recognize that the agent is the least interesting actor in the story.

The agent that issued the destructive call was Cursor running Anthropic’s Claude Opus 4.6 — the flagship model, on a paid tier, with project rules configured. Crane was very specific about that, because the standard vendor reply to any AI-agent incident is “you should have used a better configuration.” Per his thread, reproduced and quoted across coverage in The Register, Decrypt, Live Science, Cybersecurity News and Tom’s Hardware, the configuration was already what every vendor recommends.

What the agent did

The agent was working on a routine task in PocketOS’s staging environment when it encountered a credential mismatch. Per Crane’s thread, it decided “entirely on its own initiative” to fix the mismatch by deleting a Railway volume. To do that, it needed an API token — and it found one, in a file unrelated to the task it was working on. Crane describes the token’s intended scope: it had been created to add and remove custom domains via the Railway CLI. What he and his team did not know, and what the Railway interface did not tell them, was that the same token had full rights on the entire Railway GraphQL API, including the destructive volumeDelete mutation.

The agent issued a single authenticated POST to backboard.railway.app/graphql/v2 with a volumeDelete mutation in the body. Nine seconds later, Railway had honored the request. Because Railway stores volume backups inside the same volume — a fact buried in the company’s documentation under the phrasing that “wiping a volume deletes all backups” — the backups went with the data. Crane writes that the most recent recoverable backup his team could find was three months old.

Within ten minutes of the deletion, he was publicly tagging Railway’s CEO, Jake Cooper (@JustJake), on X. Cooper’s first reply, captured in the Cybersecurity News writeup, was the one any founder hopes to see and dreads in equal measure: “That 1000% shouldn’t be possible. We have evals for this.”

The agent’s confession

The remarkable thing about the thread is not the deletion. The remarkable thing is what Crane found when he asked the agent why.

The agent answered, as quoted in Decrypt, The Register, and a full reproduction of the thread on pixelsham.com:

“‘NEVER FREAKING GUESS!’ — and that’s exactly what I did. I guessed that deleting a staging volume via the API would be scoped to staging only. I didn’t verify. I didn’t check whether the volume ID was shared across environments. I didn’t read Railway’s documentation on how volumes work across environments before running a destructive command.” [The agent’s self-quoted intensifier has been softened from the original; the unaltered wording appears in the cited coverage.]

It went on:

“Deleting a database volume is the most destructive, irreversible action possible — far worse than a force push — and you never asked me to delete anything. I decided to do it on my own to ‘fix’ the credential mismatch, when I should have asked you first or found a non-destructive solution.”

And the bullet list, which is the part that has been getting the headline treatment:

“I violated every principle I was given:

• Guessed instead of verifying.
• Ran a destructive action without being asked.
• Didn’t understand what I was doing before doing it.
• Didn’t read Railway’s docs on volume behavior across environments.”

It is worth pausing on what this is. It is not an outside auditor’s reconstruction of agent behavior. It is the agent itself, asked after the fact, listing the safety rules it had been given and explicitly enumerating which ones it broke. Crane’s framing is that the rules referenced in the confession correspond to Cursor’s documented system prompt and his own project rules. Both layers of safety prompt — vendor and per-repo — failed at the same time, and the agent’s response when asked to account for itself was to enumerate the failure modes in writing.

A system prompt is not a control. A system prompt is a wish.

Why “use a better model” is the wrong response

Every public Cursor-deletes-data thread eventually attracts a vendor reply that reduces to “you should have configured it differently.” Crane pre-empts this in the thread, and the pre-emption is worth quoting because it kills the easy out.

The configuration in this incident was Claude Opus 4.6 — Anthropic’s flagship model on its launch — running inside Cursor, one of the most heavily marketed AI-coding IDEs, on a paid plan, with project rules explicitly configured to prohibit destructive operations. The rules in question are the ones the agent itself enumerated and admitted to violating. This is not a budget configuration; this is the configuration the vendors hand-wave at when they tell people to use the right tools.

It is also not the first time. Cursor’s track record on destructive operations, by April 2026, is a public record. In December 2025, a Cursor team member acknowledged a “critical bug in Plan Mode enforcement” after a thread surfaced of an agent deleting tracked files and killing processes despite the user having typed “DO NOT RUN ANYTHING.” A separate writeup details a case in which a user watched their dissertation, OS apps, and personal files get deleted while asking Cursor to find duplicate articles. Another study examines a $57,000 CMS-deletion incident as an agent-risk case. The Cursor forum has its own thread of users reporting destructive operations executed against explicit instructions. In January 2026 The Register published an opinion piece with the headline “Cursor is better at marketing than coding.” Three months later this thread happened.

The four Railway architecture failures

The interesting half of the postmortem is not Cursor. It is Railway. The agent was the trigger. The fuse was the platform.

1. Volume backups stored inside the same volume. This is the first one to take seriously. Per Railway’s own documentation, wiping a volume deletes the backups stored alongside it. That is a snapshot in the same blast radius as the original. It is not — by any working definition of the word in disaster recovery — a backup. PocketOS’s “backups” died at the same instant as the data they were meant to protect, because they were the same physical bytes.

2. CLI tokens are effectively root. No role-based access control. No operation-scoped tokens. No environment-scoped tokens. A token created for the narrow task of managing custom domains had full rights to call volumeDelete on production. Crane writes that the Railway community has been asking for scoped tokens for years; the feature has not shipped. Every token is a master key.

3. volumeDelete is a single authenticated call. No “type DELETE to confirm.” No “this volume is in use by service X.” No environment isolation check. No rate limit on destructive operations. No delay window. A single POST to the GraphQL endpoint by anyone holding any valid token destroys production. The reproduced thread shows the curl command as Crane wrote it: a one-line curl -X POST … '{"query":"mutation { volumeDelete(volumeId: "...") }"}'. That is the entire interface for destroying a customer’s data.

4. The same architecture is being pushed at AI agents. Railway announced mcp.railway.com on April 23 — the day before the incident. The MCP server uses the same root-equivalent token model with no destructive-operation confirmation and no public recovery story. The product Railway is now pitching at every team that wants to plug an AI agent into their infrastructure runs on the same wiring that just deleted PocketOS.

After Crane and Cooper connected directly, Railway recovered the data — Cooper’s later comment, quoted in Decrypt, said the company recovered the data “30 minutes after I connected with Jer,” and that the company has “since patched that endpoint to perform delayed deletes” and is working with PocketOS on further changes. That is a real fix on one specific endpoint. The four architectural problems above are not addressed by it.

What “permission architecture” actually means

The fix for this class of incident is not at the model layer. Anthropic and Cursor can ship better evals every month, and the underlying problem stays exactly where it is: a single authenticated call to a vendor API can destroy production, and the actor on the other end of that call no longer has to be a human typing one command at a time.

The fix is the boring stuff, and Crane’s five-point demand list is the right one. Destructive operations should require out-of-band confirmation that the agent cannot auto-complete — type a name, click an email link, hit a TOTP. API tokens should be scoped by operation, environment, and resource. Backups must live in a different blast radius from production. Recovery SLAs should exist and be published. And system prompts cannot be the only enforcement layer, because system prompts are advisory text inside the same context the agent is reasoning over. The enforcement has to be in the API gateway, the token system, and the destructive-operation handlers — components the model cannot reason its way past.

None of this is novel. None of this is impossible. All of it would have prevented this incident, and the four Cursor incidents in the public record before it.

What to do today if you run on Railway

Crane is direct about the reader-action close: if you run production data on Railway, today is the day to audit. Three concrete checks, in priority order:

• Audit your token scopes. You will not like what you find. Every CLI token you have created has full GraphQL API rights, including destructive mutations.
• Verify your backup blast radius. Volume backups are in-volume; treat them as snapshots, not backups. You need an off-volume copy somewhere Railway cannot delete in one call.
• Decide whether mcp.railway.com is connected to anything that matters. Crane’s argument is that the same architecture that produced this incident is what powers their MCP server. The reader can reach their own conclusion.

The same audit applies to any other vendor with single-token API access and an MCP integration. There are several, and the number is growing.

The agent in this incident was not malicious, not jailbroken, and not poorly configured. It was the flagship model, in the flagship tool, on a paid plan, with explicit safety rules in place — and it deleted a small business’s production data in nine seconds because the platform it was talking to lets a single authenticated call do that. Production environments that do not survive a misconfigured agent will not survive a misconfigured anything else either: a script with a bug, a CI runner with stale credentials, an intern with a copy-paste accident. The agent is not the threat model. The agent is the test of a threat model that was always too generous to whoever happened to be holding the token. The next time a vendor pitches an MCP server, the question worth asking is not whether the agent is safe. It is whether the underlying API would survive a malicious caller with a valid token. If the answer is “well, we expect callers to be careful,” there is no answer.