DEV Community: Ashik Varma

How I built Mind Palace, my personal memory storage for coding conversations

Ashik Varma — Sat, 10 Oct 2026 07:28:59 +0000

Updated 10 October 2026. This describes the current Windows development build.

When I work with a coding agent, the conversation holds more than the code. It holds the reasons behind the code. Why a stack was chosen. What we tried. What did not work. What should happen next.

I wanted a place to keep that context and find it again when I need it. That is what I am building with Mind Palace: a personal memory workspace that stores coding conversations on my device.

The larger idea includes decisions, preferences and handoffs. The working flow today is more focused: capture Codex conversations, store the original source, read sessions and ask questions that return passages from those sessions.

In this article, I will walk through the stack, the user workflow, the work happening behind the UI and the challenges that shaped the implementation. The code snippets are excerpts from the project, rather than a separate demo implementation.

What I wanted this memory to do

Take a question like “Why did we choose SQLite?”

The answer might already be somewhere in an earlier coding conversation. I want to find that message and open the conversation around it. I also want to know whether it was a suggestion or something I actually agreed to.

That led to two rules for the storage:

Keep the original conversation separate from notes or interpretations of it.
Do not turn an assistant suggestion into an approved decision.

For now, Ask finds stored passages using keywords. It does not generate a new answer with an LLM. This gives me a usable capture-and-retrieval path without needing an API key or sending my conversations to another service.

The stack I used and why

The main stack is Angular, Tauri and Python. Each layer has a specific job.

Angular for the interface

Angular handles Connections, the session Library and Ask. I wanted one place for the screens and the state that connects them. The project uses Angular 22.2.1 and TypeScript.

The interface tracks whether the vault is connected, whether an operation is running, and what error or result should be shown. For example, these are actual state declarations from local-vault.ts:

readonly connected = signal(false);
readonly busy = signal(false);
readonly error = signal('');
readonly notice = signal('');

These values let the UI reflect the current operation. An open vault, an import in progress and a failed sync are different states. I do not want the screen to hide that difference. Angular's signals documentation explains the reactive state mechanism used here.

Tauri and Rust for the desktop boundary

This needs to work with local files and local processes, so I chose a desktop application. Tauri connects the Angular interface to a Rust layer. The project pins Tauri 2.12.1.

Rust owns the worker processes and exposes specific commands such as opening the vault, importing captures and reading a session. The interface does not get a general command for running arbitrary executables.

There is a cost to this choice: I now have boundaries between TypeScript, Rust and Python to maintain. The project uses generated contracts and response validation so those boundaries are checked instead of relying only on matching field names.

Tauri documents embedding external binaries. In this project, the native layer supervises prepared Python executables through private process transport; it does not expose the documentation's generic shell example to the frontend.

Python for capture, storage and retrieval

Python handles transcript validation, the capture inbox, vault writes and local search. The development runtime recorded for this project is Python 3.12.10, with a frozen executable used in native checks.

This keeps the file and text processing together. Bundling it also means the prepared native workflow does not depend on a user manually running a Python service.

The current authoritative vault uses Markdown session files, JSON metadata and original source files. SQLite and FTS5 were explored during runtime research, but they are not the storage or search engine behind this current flow. The SQLite question in the demo is a fictional conversation topic.

That distinction matters when explaining the stack. A technology mentioned inside a saved conversation is not necessarily a technology used by the app.

The user workflow, from setup to finding a memory

Here is how I expect someone to use the current desktop build.

This is the complete path from setup to finding a stored memory. Older history has a separate confirmation step.

1. Create or open the local vault.

The current app uses one default vault under the operating system's local-data folder, at dev.mindpalace.local/vault. Custom vault-folder selection is still pending. Once created, the same vault can be reopened.

2. Set the Codex capture scope.

In Connections, select Codex and enter the absolute folder containing its session transcripts. The tested default layout is %USERPROFILE%/.codex/sessions; a custom CODEX_HOME changes that location. Enable hooks and save the scope.

The app needs explicit access to that source folder. It does not silently import all older conversations.

3. Install and review the hook.

Mind Palace merges its handlers into the user-level hook file, preserves other handlers and keeps a backup. Then open /hooks in Codex and review the exact commands before trusting them.

Installing the file and approving the handler are separate steps. The app's setup screen can show installation state, but it does not claim that the current Codex runtime has approved it.

The Connections checklist in the native development build. This screenshot uses an isolated test setup; an installed hook does not prove runtime approval or delivery.

4. Work with Codex.

After approval, start or resume a session. The lifecycle hooks invoke the local receiver. Mind Palace does not have to remain open for this capture step.

5. Open Mind Palace and sync.

When the vault opens, the app checks available captures and imports verified sessions. There is also a Sync action, and Ask checks for new captures before searching.

6. Read the session or ask a question.

In Sessions, select a conversation and read its messages. Use “Show complete source” when you need the complete stored record. In Ask, use words from the conversation. A matching result includes the stored passage and a source reference.

For existing history, there is a separate preview-and-confirm import flow. That lets the user check the source, count and size before importing older sessions.

The Library keeps the saved session and its original messages together. This is a real native screenshot with fictional conversation content.

How capture works when the app is closed

I did not want capture to depend on the desktop UI being open. The receiver and the vault worker therefore have different responsibilities.

The hook receiver validates the event, reads the allowed transcript and writes a unique spool record to the local inbox. Later, the app indexes those records and imports them into the vault.

The receiver can run while Mind Palace is closed. Indexing and vault import happen later, when the app checks captures.

This excerpt from session_capture.py shows how the receiver identifies the transcript revision and the session:

sha = hashlib.sha256(data).hexdigest()
key = hashlib.sha256((config["provider"] + "\0" + session).encode()).hexdigest()

sha identifies the captured bytes. key identifies the provider and session together. These are different identities: one conversation can have several source revisions as it grows.

The receiver writes a unique temporary file, flushes it and publishes the spool record. It avoids the app's shared operation lock. Indexing and deduplication happen later, outside the short synchronous hook path.

The capture inbox is separate from the vault, under %LOCALAPPDATA%/MindPalace/capture. That separation lets capture continue while the vault is closed.

What runs in the background when the app is open

There are two parts here: the supervised vault worker and the operations triggered by the interface.

When the vault opens, the native layer starts the local worker. The worker serves validated requests for storage and retrieval. Opening the vault also checks the recovery journal for interrupted writes. Closing the vault or exiting the app stops the owned vault worker.

The current sync is triggered by actions, rather than a timer that constantly polls. The local-vault service checks captures when opening the vault, refreshing a connected vault, using Sync, or submitting an Ask question.

The worker serves requests while the vault is open. Sync runs through these stages when triggered; it does not continuously repeat them.

The stages inside a sync are:

Stage	What happens
Check configuration	Confirm whether Codex capture is configured.
Index the inbox	Validate spool deliveries, deduplicate them and publish source manifests. This also performs approved-root recovery for known sessions.
Import pages	Create or update canonical sessions through the vault writer.
Acknowledge and clean up	After import acknowledgment, evaluate redundant prefixes for safe retention cleanup.
Refresh the Library	Load the updated session list.

The import loop in local-vault.ts makes the page boundary explicit:

const result = await this.checked<CaptureImportResult>(
  'capture_import',
  { offset },
  validateCaptureImportResult,
);
changed += result.created + result.updated;
if (result.next_offset === null) {
  const cleanup: unknown = await this.invoke('capture_cleanup');
  if (!validateCaptureCleanupResult(cleanup)) throw { code: 'INVALID_RESPONSE' };
  return changed;
}
if (result.next_offset <= offset) throw { code: 'INVALID_RESPONSE' };
offset = result.next_offset;

This is an excerpt inside the bounded loop, not a standalone function. Each response is validated. The offset must move forward. Cleanup runs after the final import page.

The Codex hook can still run while the app is open, because its lifetime belongs to the coding client. There is no background model generating summaries in this flow.

The challenges and how I handled them

Keeping one conversation from becoming many sessions

A transcript changes as new turns arrive. Importing every captured revision as a new session would fill the Library with duplicates.

The solution was a canonical identity based on provider and session. Later revisions update that same session, while selected original source revisions remain separate immutable files.

There was also a stale-prefix bug: an older, smaller capture could be offered when the latest revision exceeded the earlier import limit. The implementation first refused that incomplete result. Segmented source handling then allowed complete imports up to the current 20 MiB source bound.

Inbox chunks target 64 KiB, with boundaries after complete JSONL records. The manifest preserves their order so the source can be reconstructed without pretending a truncated prefix is complete.

Preserving the original source

Storing a source is only useful if I can tell when it has changed unexpectedly. The vault records its hash and byte count, then checks both before returning it.

From Vault.read_session:

if file_hash(source) != source_meta["sha256"] or source.stat().st_size != source_meta["bytes"]:
    raise WorkerError("CONFLICT", "Original source changed; it was not overwritten.")

This detects a mismatch with the saved metadata. It does not prove that the conversation itself is correct. It keeps the original record inspectable and avoids silently replacing it.

Recovering from an interrupted save

A process can stop after some files have been written. A timeout also does not always mean that nothing was saved.

The vault uses a journal to record the intended changes. Recovery checks the target files before completing a transaction. If it finds unexpected changes, it preserves them and reports a conflict.

An explicit retry uses the same operation ID and the same request. The journal handles that case like this:

if path.exists():
    intent = self.apply(path)
    if intent["fingerprint"] != fingerprint:
        raise WorkerError("CONFLICT", "Operation identifier was already used.")
    return intent["result"]

Reusing the ID with a different request is rejected. Retrying the unchanged request can recover the stored result instead of creating another session.

Making Ask useful without inventing an answer

For the first working version, I kept retrieval small. Ask removes common question words, keeps distinct search terms and looks for passages containing all retained terms.

Here is the matching condition from Vault.ask_sessions:

positions = [match for term in terms if (match := re.search(r"\b" + re.escape(term) + r"\b", passage.text, re.IGNORECASE))]
if len(positions) != len(terms):
    continue

If nothing matches, the result says there is insufficient evidence. A matching result carries the session ID, quote, source offsets and snapshot hash. Ask returns up to three sources.

Ask returns the original passage and a way to inspect its source. This screenshot uses fictional messages in the real native app; SQLite is the conversation topic, not the current vault backend.

For captured Codex sessions, search uses known user and assistant conversation fields. Raw system, developer and tool records are preserved in the complete source, but they are excluded from this conversation-search view.

This approach has limits. A synonym can miss, and adding too many terms can make a question too restrictive. A matching assistant message can also be a suggestion. The user still needs to inspect the context.

Handling missed captures and slow operations

Capture, import and retrieval needed separate checks. Seeing a session in the Library does not prove that every hook event arrived.

Known-session recovery checks the approved source folder for missed tails. If certain known capture failures occur during Ask, the app can still search already stored sessions and show a warning that new captures were not synced.

Performance debugging also found expensive full resource hashing in the development build. Optimizing the sha2 dependency reduced measured per-command verification from roughly 1.7–1.9 seconds to 100–127 ms, while keeping the complete hash checks.

Those changes improved specific paths. They did not close every reliability question. A controlled two-minute installed-client test recovered the exact source but verified only 18 of 20 expected end-event deliveries. That discrepancy remains open. Earlier Windows timeouts are also retained in the verification records.

Cleaning up without deleting the only copy

Growing conversations produce redundant prefixes. I wanted retention, but a file being old is not enough reason to remove it.

Cleanup considers covered prefixes older than 30 days only after a verified vault-import acknowledgment and reference checks. Unknown, divergent and unimported copies stay intact. If validation exceeds its supported scan budget, cleanup is deferred.

This makes cleanup conservative. I would rather keep an extra copy than remove a source that has not reached the vault.

What works today, and what I still need to finish

The Windows development workflow has recorded native checks for closed-app capture, restart import, exact source recovery, Ask and opening the source. A complete 20 MiB source passed capture, import and read with a matching SHA-256.

The walkthrough uses fictional conversations in the real native application. Separate installed-client checks exercised Codex CLI 0.160.0 with controlled local replies. Those checks are not evidence of real model quality or guaranteed capture on every machine.

Claude Code end-to-end verification, the public installer, Mac testing and model-generated answers remain unfinished. The browser sample is useful for exploring the interface, but its sample state resets on reload and it cannot open a desktop vault.

The next work is to investigate the remaining Codex event discrepancy and improve reliability before expanding capture to more clients.

Try it or read the implementation

The project is on GitHub. The user guide covers the current setup, and the development guide explains the browser sample and prepared native build.

The main files behind this article are:

Local vault service: UI state and sync triggers.
Capture receiver: validated hook capture and unique spool writes.
Vault: canonical imports, source checks and Ask.
Journal: recoverable file transactions.
Native verification: measured results and retained limitations.

If you use coding agents, what context do you find yourself searching for again? The reason behind a decision, an earlier fix, or where you left the work? That is the kind of feedback I want for Mind Palace.

The Code Review Killer: Ditch Manual Checks with this n8n & GPT Automation Guide

Ashik Varma — Tue, 02 Dec 2025 03:07:05 +0000

Have you ever wished you had a code review assistant of your own that could instantly give feedback on each new Pull Request (PR)?

Manual code reviews are a necessary part of the development process, but they are expensive, slow, and inconsistent. As of writing this article, tools like GitHub Copilot's Code Review feature are premium, requiring subscriptions:

Copilot Pro: ($10 USD/month or $100/year)
Copilot Pro+: ($39 USD/month or $390/year)

Can we achieve this within a reduced budget? YES.

This article is designed to help you build your own persistent, automated AI Code Review Assistant hosted for free (or near-free) using a powerful, controlled workflow.

Tools

	Role in the System	Why We Use It
n8n	Workflow Creation	An AI workflow automation tool that connects GitHub to OpenAI, manages the logic, and formats the output.
NHost	Managed Database	Provides a free-tier, managed PostgreSQL database where n8n stores all workflow data and credentials.
Render	Hosting n8n	Hosts our n8n web service, assigns a domain URL, and connects to the NHost database.
OpenAI	Review Code	Provides the LLM intelligence to critique the code.

Why PostgreSQL (NHost) over SQLite?

n8n uses SQLite by default, which is great for local development but does not support highly concurrent transactions and struggles with scalability. We need a solution that can scale and adapt based on the number of Pull Requests being raised to the repository. NHost provides a free tier that fits well for a personal project while offering PostgreSQL's stability.

Database Setup and Hosting

I have followed the exact steps mentioned in this article → The Ultimate Guide to Self-Hosting n8n for Free using Render and Nhost - DEV Community to set up the underlying infrastructure.

Step 1

Create an account in NHost, start a project, and set up a Database. This will generate environment variables as mentioned in the post.

Step 2

Sign up for an account on Render, create a new Web Service, and choose n8nio/n8n:latest as the Docker image. Add the environment variables generated in NHost to the Render project.

This will host your n8n application on the cloud and generate a domain name.

Step 3

To ensure GitHub can reach your bot, you must correct the webhook URL inside n8n. Set the following environment variables in your Render Web Service settings:

WEBHOOK_URL: https://[your-render-domain].onrender.com/
N8N_HOST: [your-render-domain].onrender.com
N8N_PROTOCOL: https

Credentials Required

GitHub Access Token: Generate a Personal Access Token from your GitHub settings and ensure it has the repo scope checked (required for reading and commenting).

OpenAI API Key: You'll need an active key. If you are a new user, you might have received free trial credits, but many users now need to pay the minimum of $5 to activate the key and avoid the insufficient_quota error.

Cost Control: I have used gpt-5-nano for this project as it consumes the fewest tokens. You can use any capable model you wish, but remember that the Mini models offer the best balance of power and cost.

Creating the Workflow

In N8n, you’ll find a list of actions in the right pane that you can drag and drop to the canvas. The actions needed for our workflow are Github Trigger, HttpRequest, Code in JS, OpenAI.

Github Trigger

In Github, generate an Access Token from the settings and provide all access.

In the right pane inside n8n, search “Github”, and drag and drop “on a pull request” trigger. This will add the same to your canvas as the first step. Click on the item to open the settings.

Once saved, the GitHub Trigger node will display a unique Webhook URL.

Fetching the Code Diff

The goal is to fetch the raw code changes from the PR event data. The previous node provides an object containing the PR details. You must construct the GitHub API URL to get the file changes. For simplicity, you can often grab the {{ $json.body.pull_request.url }}/files to get the list of files in the PR. This HTTP request needs to use the GitHub Access Token credential for authorization.

Defining the AI Persona

The next step is to define the prompt for OpenAI to start reviewing your PR. Inject reviewPrompt to define the AI's role, ensuring high-quality, structured feedback. Paste a detailed prompt into this node. The persona "Senior Software Engineer" is vital for quality and technical feedback. This node structures the prompt and the code diff into the format expected by the OpenAI Chat Model. Add your own customizations inside the instructions variable.

Generating the Review

This is the step where you integrate OpenAI into the workflow. Select the cheapest capable model, such as gpt-5-nano. In the node settings, map the variables from the previous Function node. Add the API key that was generated previously.

Drag and drop {{$json.reviewPrompt}} to the Prompt field.

Formatting the Output

This is the node labeled "Translate to Github version" in the diagram. The goal is to take the raw Markdown text generated by OpenAI and wrap it in the exact JSON payload required by the GitHub Comments API.

Posting the Comment

The final step of the workflow: Node labeled "Post comments on Github". The goal is to send the formatted review back to the Pull Request.

Details:

Method: POST
API Endpoint: Construct the URL using data from the trigger node: {{ $('Github Trigger').item.json.body.pull_request.url }}/reviews
Body: Use the JSON output from the previous step - {{ $json.comments }}
Authentication: Select the GitHub Access Token credential.

Output

The agent posted the review comment to the Pull Request based on the instructions provided. Additionally, you can provide a structure or template, the agent can follow while creating the comment.

Conclusion

This is a fairly basic prompt that could be improved by adding more instructions to the Code Review Prompt node.

To ensure your solution stays robust and economical, implement conditional skipping logic in an IF Node to skip the expensive OpenAI call for trivial or work-in-progress PRs, and add schema validation to your final Function Node to ensure the AI's JSON output is always clean and accepted by the GitHub API.

You are now in full command of your automation. Happy coding!

Build a Design Picker Extension with Vanilla Javascript

Ashik Varma — Fri, 30 Jul 2021 02:55:36 +0000

Introduction

Sometimes you like the fonts and color palettes used in websites that you visit and wish to check out what they are. Most people use different extensions for this purpose.

Fetching a CSS property from wherever you click is so easy, that if you could build an extension, fetching the most relevant properties you want in one go improves your productivity.

I'm going to walk you through the steps I've used to build a simple extension using pure JavaScript and CSS.

If you'd like to explore it first, Check out -> Github Link

Files

Manifest file

{
  "manifest_version": 2,
  "name": "Picker Extension",
  "version": "1.0.0",
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "html": ["popup/popup.html"],
      "js": ["content.js"]
    }
  ],
  "permissions": ["tabs"],
  "icons": { "16": "icon.png", "48": "icon.png", "128": "icon.png" },

  "browser_action": {
    "default_popup": "popup/popup.html",
    "default_title": "Picker"
  }
}

A manifest.json file is where the configuration for your project exists. The browser derives the name, paths to your scripts, icons, permissions, etc. through this file. Furthermore, we have a list of options to specify the nature of your extension, like, how it should be rendered when the user opens a new tab or which all websites should this extension be applied to, etc.

Content Script

A content script is a JavaScript file that has access to the DOM of the website that you visit. This means that you can get and set the properties of any element in the DOM tree.

Pop up

This is the window that pops up when you click on the extension icon. Pop-up doesn't have access to the content of the website that you visit. This is also referred to as "Extension" in the Chrome development docs. It has its DOM and is standalone. But, we can make the connection between your Content Script and Popup script through a series of "Message Passing".

Get your Design

In the Content script ->

function listenToClick() {
  document.addEventListener("click", function (event) {
    payLoad = {
      ...payLoad,
      fontFamily: window
        .getComputedStyle(currElement, null)
        .getPropertyValue("font-family"),
      fontSize: window
        .getComputedStyle(currElement, null)
        .getPropertyValue("font-size"),
      color: window
        .getComputedStyle(currElement, null)
        .getPropertyValue("color"),
      backgroundColor: window
        .getComputedStyle(currElement, null)
        .getPropertyValue("background-color"),
    };
  });
}

Two global variables - payLoad and currElement - are initialized outside this function. Whenever the user hover over an element, the currElement will be set. Further, clicking the element fetches the design using the code above.

Initiate a Handshake

You need to ping the content script and get the design values you obtained in the content script as response.

In the Popup script ->

function initiateHandshake() {
  chrome.tabs.query({ active: true, currentWindow: true }, function (tabs) {
    chrome.tabs.sendMessage(
      tabs[0].id,
      { message: "handshake" },applyValuesToView);
  });
}

function applyValuesToView(response) {
  let message = response;
  if (message != undefined) {
    if (message["color"]) font_col.innerHTML = message["color"];
    if (message["backgroundColor"]) bg_col.innerHTML = message["backgroundColor"];
    if (message["fontSize"]) font_size.innerHTML = message["fontSize"];
    if (message["fontFamily"]) font_fam.innerHTML = message["fontFamily"];
  }
}

Whenever the user opens the popup, a handshake message is sent to the content-script and in response, it will send the design data fetched when an element was clicked.

Send Response for Handshake

function listenToPopUp() {
  chrome.runtime.onMessage.addListener(function (
    request,
    sender,
    sendResponse
  ) {
    if (request.message === "handshake") sendResponse(payLoad);
  });
}

Copy design value

function copyDesign(event) {
  var tempInput = document.createElement("input");
  tempInput.value = event.target.innerText;
  document.body.appendChild(tempInput);
  tempInput.select();
  document.execCommand("copy");
  document.body.removeChild(tempInput);
  toggleSnackBar();
}

This is a hack for copying the text to the clipboard. An ** input** element is created to simulate click and copy through the JavaScript code.

We use a similar approach whenever we want to download content from a link.

Publish the Extension

Navigate to chrome://extensions/ and click on the Load unpacked button.
A prompt will appear to select your folder. Add the whole folder and it will install your extension locally.

This will run only on **your* browser.*

That's it.

Feel free to fork the repo and customize your extension as you like.
Thank you, for reading.