CodexA: Open-Source AI Code Intelligence Engine for Developers

Mounir Elsrogy — Mon, 09 Mar 2026 19:42:49 +0000

What is CodexA?
CodexA is a blazing-fast, open-source code intelligence engine for developers. It brings AI-powered search, symbol explanation, dependency analysis, and more—directly to your local machine, CLI, or editor.

Local-first: All code analysis runs on your machine. No cloud lock-in, no privacy risk.
Rich CLI & API: 30+ CLI commands, REST API, and a web UI.
AI Agent Protocol: Integrates with GitHub Copilot, LLMs, and custom agents for deep code understanding.
Multi-language: Supports Python, JavaScript, TypeScript, and more via Tree-sitter parsing.
Architecture Overview
CodexA is built for extensibility and speed:

Core Engine: Handles code indexing, semantic search (FAISS), and embeddings (sentence-transformers).
CLI & Tools: 30+ commands for search, symbol explanation, call graphs, impact analysis, and more.
Plugin System: 20+ hooks for custom tools, LLM providers, or new languages.
Web UI & REST API: Modern VitePress docs, interactive dashboard, and REST endpoints.
Self-Evolving: Built-in evolution engine for self-improving code and docs.
For a deep dive, see the architecture reference.

Why Use CodexA?
OSS maintainers: Instantly answer “where is this used?” or “what breaks if I change this?” across huge codebases.
Plugin authors: Build custom AI tools, integrate new LLMs, or add language support with minimal friction.
Teams: Run secure, local code search and analysis—no data leaves your machine.
Key Features
Semantic code search (natural language or symbol-based)
Symbol explanation, call graphs, and dependency trees
Impact analysis (“blast radius” for code changes)
Quality metrics, hotspots, and code review helpers
VitePress-powered docs and contributor guides
GitHub Actions workflow for auto-deploying docs (with custom domain support)
Get Started
GitHub: M9nx/CodexA
Docs: codex-a.dev
Install: pip install codexa (Python 3.8+)
Try: codex search "find all database queries" in your repo
Feedback & Contributions
Star the repo, open issues, or join the discussion on GitHub. Contributors wanted—especially for new language plugins and LLM integrations.

Exploring Runtime Request Inspection in Laravel (Guards, Contexts, and Tradeoffs)

Mounir Elsrogy — Tue, 06 Jan 2026 13:18:49 +0000

Exploring runtime request inspection in Laravel

I’ve been experimenting with a Laravel package that inspects requests during runtime, not just before the controller is hit.

This started as a question rather than a solution:

Can runtime context inside the framework give better security signals than static request inspection?

So I decided to prototype it.

Core idea

Instead of relying only on:

validation rules
middleware checks
edge security (WAF, CDN rules)

The package builds a RuntimeContext once the request is already inside Laravel and runs a pipeline of Guards against it.

Each guard inspects a different aspect of the request or behavior.

Architecture (high level)

RuntimeContext
- Normalized request data
- Headers, body, route info
- Execution metadata
- Optional historical signals
Guards
- Small, focused inspectors
- Priority-based execution
- Can short-circuit or aggregate results
- Return structured GuardResult objects
Profiles
- Group guards per route or use-case
- Different behavior for APIs vs admin routes
- Different enforcement modes
Response modes
- log only
- silent
- block
- dry-run (full inspection, no enforcement)

Guards implemented so far

Examples (not claiming completeness):

SQL injection (pattern-based + heuristics)
XSS indicators
SSRF attempts (internal IPs, metadata endpoints)
Mass assignment abuse
PHP deserialization vectors
NoSQL operator injection
GraphQL depth / complexity abuse
Bot & anomaly behavior (experimental)

Each guard:

is configurable
can be enabled/disabled at runtime
has a defined cost / priority

Performance considerations

This was a big concern, so I added some experiments:

Deduplication cache for repeated payloads
Sampling (inspect % of requests, always inspect suspicious ones)
Tiered inspection (fast scan → deep scan)
Guard-level and pipeline time budgets

Still very much unproven in real production traffic.

What this is NOT

Just to be clear:

Not a replacement for validation
Not a WAF
Not claiming to “block all attacks”
Not production-ready yet

This is more of a design experiment around:

guard composition
runtime context modeling
tradeoffs between signal quality and overhead

Why I’m sharing this

I’m mainly looking for feedback on:

architecture choices
guard interface design
things that are fundamentally flawed
existing projects that already solved this better

If you’ve worked with:

Laravel internals
PHP security tooling
request lifecycles
or runtime analysis systems

I’d love to hear your thoughts — positive or negative.

Links

GitHub (source & issues):
https://github.com/M9nx/laravel-runtime-guard

Packagist:
https://packagist.org/packages/m9nx/laravel-runtime-guard

If this turns out to be a dead end, that’s fine — I mainly want to understand why.

Any feedback is appreciated 🙏

DEV Community: Mounir Elsrogy