DEV Community: Rohith Matam

The Redis URL That Leaked Its Own Password Into AI Agent Context

Rohith Matam — Thu, 16 Jul 2026 16:50:56 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

ContextOS is a context operating system for AI coding agents: it scans a repo, ranks the relevant files, and builds a context pack under a token budget for the agent to work from. Before anything goes into that pack, a secret detector redacts API keys, tokens, and credentials so agents never see live secrets, published on PyPI with 980+ automated tests and an 80% coverage gate.

Bug Fix or Performance Improvement

The database_url secret-detection pattern was supposed to catch connection strings like postgres://user:password@host and redact the password. It required at least one character for the username segment before it would match. That's fine for Postgres and MySQL, which always have a username. It's not fine for Redis, where the standard URI convention is redis://:password@host, no username at all, just a password. That empty-username shape silently failed the pattern's [^:@/\s]+ requirement, so detection was skipped entirely. The password sailed straight into the context pack, unredacted, ready to be handed to an LLM agent.

I found it while auditing detection coverage against real-world connection string formats rather than just the formats already covered by existing tests. The exact format Redis's own documentation recommends when only a password is configured didn't get caught.

Code

PR: Rohithmatham12/ContextOS#1

Before (username segment requires 1+ chars):

r"(?i)(?P<key>(?:postgres(?:ql)?|mysql|mongodb(?:\+srv)?|redis)"
r"://[^:@/\s]+:)"
r"(?P<value>[^@\s]{4,})"
r"(?=@)"

After (username segment allows 0+ chars):

r"(?i)(?P<key>(?:postgres(?:ql)?|mysql|mongodb(?:\+srv)?|redis)"
r"://[^:@/\s]*:)"
r"(?P<value>[^@\s]{4,})"
r"(?=@)"

Before, this stayed exactly as-is, verbatim, in the context pack handed to the agent:

REDIS_URL=redis://:supersecretpass123@cache.internal:6379/0

After:

REDIS_URL=redis://:[REDACTED_DB_PASSWORD]@cache.internal:6379/0

My Improvements

One character, + to *. That's the entire regex fix, but the real work was proving it was safe: I added two regression tests covering both detection and redaction for the empty-username case, then ran the full suite: 952 passed, 2 skipped, no regressions.

This isn't a cosmetic bug. ContextOS exists specifically to hand code to AI agents safely. A credential-detection gap in that exact pipeline defeats the entire point of the tool for any project using Redis, which is most projects doing caching or session storage. The fix closes the gap for every future scan, not just the one string I tested.

The bigger lesson: test coverage that only exercises the formats you thought to write tests for will always look complete. It wasn't a logic bug so much as a coverage gap disguised as a passing test suite. The fix that matters isn't just the regex change, it's making the URL-shape assumption ("usernames are always present") explicit in a code comment so the next person doesn't reintroduce it.

Preserving Resource Attributes During Span Flattening: A Trace Data Collision Story

Rohith Matam — Thu, 16 Jul 2026 15:53:26 +0000

Tracing pipelines flatten nested OpenTelemetry data (resource attributes + span attributes) into a single flat record before storage. Simple in theory. In OpenObserve, it was quietly losing data.

The bug: When a span's attributes and its resource's attributes shared the same key, for example service_name appearing in both places, the flattening step let the span-level value silently overwrite the resource-level one. Resource attributes are supposed to be the authoritative source (they describe the entity emitting the trace); span attributes are per-operation and shouldn't be able to clobber them. But the flattening code had no collision handling at all: last write wins, whoever happened to serialize second.

That's a correctness bug that's invisible until it isn't. Your dashboards keep working. Your queries keep returning results. They're just returning the wrong service_name for a subset of spans, and nothing errors to tell you.

Root cause: No collision-avoidance strategy existed between BLOCK_FIELDS and RESERVED_SPAN_FIELDS. Two separate reserved-field lists, no coordination between them, and no prefixing scheme to keep colliding keys distinguishable during flattening.

The fix:

Resource's canonical service.name stays authoritative as service_name, full stop.
Any other resource attribute that collides gets a service_attr_ prefix instead of silently competing.
Colliding span attributes get an attr_ prefix before flattening, so they land next to the resource value instead of over it.
Merged the two separate reserved-field lists into one unified list, closing the gap that let the collision happen in the first place.
Added regression tests specifically covering the three-way collision: resource service.name, resource name, and span service_name all present at once.

Impact: Trace data integrity restored for any pipeline where span and resource attributes overlap, which in practice is common (service metadata gets attached at both levels by different instrumentation layers). The unified reserved-field list also closes the door on the same class of bug reappearing with a different field name.

Lesson: Attribute collisions are a "works on the happy path" bug class. Nothing throws, nothing fails a test that only checks the non-colliding case. The fix wasn't just patching the one field, it was building a naming convention (canonical vs. prefixed) that makes the next collision safe by construction instead of requiring another one-off fix.

PR: openobserve/openobserve#12456 (merged)

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

I built a "context OS" that stops AI agents from drowning in your codebase

Rohith Matam — Wed, 01 Jul 2026 03:44:37 +0000

The problem every AI coding session hits

You open Claude or Copilot, paste in your task, and immediately hit the wall: the codebase is too big. You either:

Dump everything and burn 80% of your context window on irrelevant files
Hand-pick files and miss the one import that breaks everything
Pay for a bigger context window and repeat the problem at scale

I got tired of this and built ContextOS — a local CLI that acts as an intelligent context layer between your repo and your AI agent.

What it does

pip install rm-contextos
cd your-project
contextos scan
contextos pack --task "add rate limiting to the auth endpoint" --budget 8000

Output: a Markdown (or JSON) context pack with only the files that matter for that task — ranked by keyword match, import graph centrality, AST symbol overlap, and git churn. Secrets redacted automatically.

Token savings report on every pack:

Packed 12 files · ~6,840 tokens · saved ~47,200 tokens (87%) vs full repo

How ranking works

Five signals combine into a score per file:

Signal	What it catches
Keyword match	Files whose content/name overlap with your task
Import graph centrality	Files that everything else imports (critical shared modules)
AST symbol overlap	Function/class names, not just grep strings
Git churn score	Recently modified files are probably active code
Secret penalty	Credential files silently excluded

No LLM calls. No cloud. Fully offline.

MCP server (for Claude Desktop / Claude Code)

pip install "rm-contextos[mcp]"
contextos serve --stdio

Register in claude_desktop_config.json and your AI agent can call pack_context, scan_repo, list_files, get_file, churn_report directly as tools — no CLI needed.

What's shipped

980 tests, 96% coverage
Apache-2.0, no telemetry, no accounts
Python 3.11–3.13, Linux + macOS
Export formats: Claude, Codex, Cursor, Aider, JSON
Incremental scan cache — re-scans only changed files

pip install rm-contextos
pip install "rm-contextos[mcp]"   # + MCP server
pip install "rm-contextos[all]"   # everything

GitHub: https://github.com/Rohithmatham12/ContextOS
Docs: https://Rohithmatham12.github.io/ContextOS/

Would love feedback — especially on the ranking signals and MCP integration. What signals are you missing?