Introducing LeakScope, again.

we've been updating it : )

LeakScope is a security scanner built for Supabase applications. Paste your app's public URL, and it checks what an attacker can learn from the outside—from exposed keys and public data access to weak RLS, leaked credentials, and insecure frontend configuration.

We've introduced two scanning modes:

Light Scan — Paste a public app URL to instantly check for exposed keys, public data exposure, leaked credentials, weak RLS, and risky frontend configuration. No account required.

Deep Scan — Authenticate to validate Row Level Security, test BOLA/IDOR, analyze JWT security, and generate detailed reports for real security validation.

Whether you're a solo founder, indie hacker, or vibe coder shipping MVPs at 2 AM, LeakScope gives you a fast way to see what your app is exposing before everyone else does.

1,936 websites scanned.
13,679 security findings identified.

Try it out at leakscope[.]tech

Hope openai won't do it 😭

I just open-sourced Context Warp Drive, a continuity engine for LLM agents.

Repo: https://github.com/dogtorjonah/context-warp-drive

Right now, the industry has two bad ways of dealing with long agent horizons:

1. Just ride the 1M-2M context window.
2. Use an LLM to summarize older messages ("compaction").

LLM summaries are inconsistent, they burn an extra model round-trip, they quietly drop the exact identifiers your agent needs (UUIDs, paths, hashes), and worst of all, they constantly rewrite the prefix—which trashes your provider prompt cache.

This library takes a different approach: deterministic folding.

As the agent works, older context is folded into deterministic skeletons. Instead of linearly bloating to the ceiling, the active context sawtooths—building up efficiently, then dropping back down to a clean floor without losing continuity.

Why not just use the 1M token window?

Because 95% of what an agent carries with it on a long task isn't needed right now. It's looking for the needle in the haystack, but massive context windows force it to carry all the hay.

A larger window raises the ceiling, but it doesn't move the floor where models reason best. Long-context evals keep showing the same thing—models do not use giant contexts as cleanly as the marketing numbers imply:

• Lost in the Middle — models degrade when needed information is buried in the middle of long context.
• RULER — large drops as context length and task complexity increase, even for models advertised as long-context.
• Context Length Alone Hurts LLM Performance Despite Perfect Retrieval — length itself hurts performance even when retrieval succeeds.
• Intelligence Degradation in Long-Context LLMs — models can collapse past critical context thresholds even when input remains relevant.

By keeping the agent deterministically folding with a warm cache and a low context band, you keep it snappy, cheap, and focused. You leave the hay behind until it's actually needed.

How Context Warp Drive works:

• The Rebirth Seed: The continuity package that makes the full reset possible. It carries the recent user and AI messages, what the agent was actively working on and editing, its execution plan state, preserved exact identifiers from the full trace, and episodic context from earlier work. It is not a vague summary—it is a structured, deterministic snapshot the agent can wake up from and continue seamlessly.
• Cache-Hot Appending: As the agent works, older turns fold into compact bands that append onto the rebirth seed. The context builds up over time, but because the seed stays byte-identical, you pay for cheap cache reads turn after turn instead of expensive fresh inputs.
• The Sawtooth Reset: You can't append forever. When measured input pressure hits your configured ceiling, the engine performs the full sawtooth—the context drops back to a fresh rebirth seed and the cycle continues from a low-context floor.
• Zero-LLM Folding: Raw chat history stays preserved as the source of truth, but the model sees a deterministic compact view. Tool calls, paths, receipts, retained reasoning, and exact identifiers are all preserved without asking another model to summarize anything.
• Episodic Recall: When the agent re-touches a path or concept from before the reset, the engine pages the relevant folded detail back in. The agent doesn't carry all the hay—it pulls it back when it matters.
• Task Rail: I also included a portable execution primitive called TaskRail. It keeps long-horizon plan state outside the prompt: steps, progress, acceptance criteria, and serializable checkpoints. Combined with folding and rebirth seeds, the agent stays low-context while still knowing exactly where it is in a multi-step workflow.

What's in the repo:

• Core folding engine, provider-agnostic across Anthropic content blocks, OpenAI-style tool_calls, and Gemini parts.
• Anthropic prompt-cache breakpoint helpers to maximize read-hits.
• Raw rebirth seed renderer.
• Model-aware context budget resolver.
• Fold recall and episodic recall (with an optional SQLite episode store).
• Portable Task Rail state machine.
• Gemini CLI and Codex CLI folding adapters.

There are a lot of knobs you can tune, but the core philosophy is the same: use the 1M window as safety headroom, not as the operating band.

(Not on npm yet—install from source for now.)

I've been running this in my own multi-agent orchestration stack for months and completely dropped LLM compaction. The difference is fundamental: the agent stops treating context as a giant backpack and starts treating it like a paged working set—small, hot, recoverable, and always grounded in the raw trace.

Been building this for a while and finally put out a first release. Not going to oversell it, just going to describe what it actually does.

The core idea came from being tired of AI tools that give you one confident answer and leave you to figure out if it's right. So I built something where the output you see has already been challenged internally before it reaches you. Not the same model second-guessing itself. A genuinely separate process with a different job, specifically designed to find problems with what was just produced.

There are two sides to the app.

The first is a council mode where you load local AI models and assign them different roles. One role breaks down your task and makes a plan. Another executes against that plan. A third receives both the plan and the result and checks one against the other. For coding tasks it actually runs the code before the reviewer sees it, so problems get caught by execution rather than by a model guessing whether it looks correct. If problems are found it either patches the specific issues or rewrites entirely depending on how bad it is. What you get at the end has been through all of that.

It also has session memory that builds up as you work, a document pipeline that processes files into structured knowledge before you start asking questions, task history, a diff view showing exactly what changed between the original output and any revision, and confidence labels on every result.

The second is a normal chat mode that runs Python, JavaScript, C#, Java and PowerShell inline and shows execution results inside the conversation. Web search with full page content extraction, LaTeX math rendering, a thinking mode, document attachment, and chat branching where you can fork from any point in the conversation.

Both modes run locally on your machine using GGUF models. If you don't want to manage model files there is a cloud mode through OpenRouter using their free models, same full pipeline, no local setup needed.

No account. No signup. No subscription. Open the app and use it.

MIT licensed. GitHub: github.com/YoMosa2009/Axiom

Happy to answer questions about anything.

I built a small free macOS tool for reviewing Codex sessions using the Codex desktop app. Are people here using anything similar to improve their AI coding workflows?

After longer Codex runs, I kept finding that the transcript was technically available, but hard to review.

The things I wanted to inspect were:

- What changed

- Which files were touched

- Where tokens went

- Which tool calls mattered

- Whether the prompt/context was good enough to reuse

- What context would be useful to share during code review

So I made BuildrAI, a local-first app that turns Codex session artifacts into timelines, token usage, prompt/session evaluation, changed-file context, and shareable reports.

I’m curious how other people are handling this.

Do you review Codex sessions after the fact, or do you mostly trust the final diff?