How mrq Works Under the Hood

When we started building mrq, we had a specific problem in mind: developers using AI assistants were losing work because the traditional git workflow doesn’t match how agents operate. We needed something that captures state automatically, stores it efficiently, and enables instant recovery.

Here’s how we approached it.

File System Monitoring

At the core of mrq is a file watcher built on chokidar, a battle-tested Node.js library that handles cross-platform file system events reliably. When you run mrq watch, we initialize a monitoring session tied to your current project directory.

We respect your existing .gitignore patterns automatically, so there’s no need to configure anything twice. The watcher debounces rapid changes (like when an agent is making multiple quick edits) to avoid capturing incomplete intermediate states. This means you get meaningful snapshots rather than noise.

$ mrq watch --daemon
Workspace created: my-project
Session started: Active work session
Watch daemon started (PID: 48291)

The daemon mode runs in the background and doesn’t block your terminal. You can continue working normally while mrq captures everything.

Deciding When to Snapshot

We don’t snapshot on every file save, as that would create too much noise and waste storage. Instead, we use content-aware change detection:

• We compute file hashes to detect actual content changes versus just timestamp updates
• Binary files (images, compiled assets, etc.) are automatically excluded since they don’t diff meaningfully
• Large generated directories like node_modules are ignored by default
• We track line-level diffs to understand the scope of changes

When we detect a meaningful change, we create a snapshot that captures the full state of your tracked files at that moment.

What’s in a Snapshot

Each snapshot contains several pieces of information:

File states: The actual content of every tracked file, encrypted before storage so even we can’t read your code.

Metadata: Timestamp, which session this belongs to, and a summary of what files changed with line counts.

Diffs: Line-by-line changes from the previous snapshot, which makes it easy to see exactly what happened between any two points in time.

AI summary: We use Claude Haiku to generate a brief, human-readable description of what changed. This runs asynchronously and doesn’t block snapshot creation.

The Restore Flow

When you need to go back, restoration is straightforward:

$ mrq restore abc123
Restoring snapshot abc123...
✓ Restored 47 files
✓ Backup created at .mrq-backup-1703001234

Before overwriting anything, we automatically create a backup of your current state. This means you can restore confidently, and if you change your mind, your pre-restore state is still there.

We also fetch files in parallel batches for performance, so even large projects restore quickly.

Storage and Security

Files are encrypted client-side using AES-256-GCM before being sent to our servers. Each user has their own encryption key, and the key itself is encrypted with a master key before storage. This means your code content is private even in the event of a server breach.

Metadata (file paths, timestamps, change summaries) is stored separately in PostgreSQL, which allows for fast querying and browsing without needing to decrypt file contents.

What We’re Working On Next

A few areas we’re actively developing:

Smarter change detection: Using the AI summary capability to identify logical change boundaries rather than just file system events.

Cross-session context: Maintaining awareness of what you were working on across multiple sessions, so the AI summaries can reference prior work.

Collaborative features: Enabling team members to share workspace history while maintaining appropriate access controls.

If you’re interested in trying mrq, we’re currently in open beta at dashboard.getmrq.com. We’d love to hear how it works for your AI-assisted development workflow.