DEV Community: Shubham Singh

I Built a Privacy Layer for AI Coding Tools — CodeMask UI and CodeMask Proxy

Shubham Singh — Wed, 19 Aug 2026 15:19:59 +0000

I was debugging a config file of my personal project and pasted it straight into Claude to get help. A few seconds later I looked at what I had actually sent: internal IP addresses, a database password, and an API key. All of it. To a cloud API. Without thinking.

I don't think I am the only one who has done this. Most developers use AI assistants daily, and most of the time the code going in contains things it shouldn't. This post is about the two tools I built to fix that — and what I learned building them.

The Problem — Two Different Workflows

Before building anything, I realized the problem has two distinct shapes depending on how you use AI.

Workflow 1 — Manual AI chat (ChatGPT, Claude.ai, Gemini)

You copy a file, paste it into the chat, ask your question, copy the response. The sensitive data goes in with the code because you are doing the pasting manually and there is no gate between your clipboard and the AI.

Workflow 2 — AI coding agents (Cline, Claude Code, Cursor)

These tools read your files automatically. When you ask Cline to explain a function, it reads the file, builds a prompt, and calls the LLM API directly. There is no paste step at all. Your secrets go out in the background with every request without you ever touching them.

Same root problem, completely different mechanism. Each needed a different solution.

Solution 1 — CodeMask UI

What it is: A browser-based tool that sanitizes code before you share it with any AI chat, and restores real values after the AI responds.

How it works: Two-way flow with a session registry.

When you paste code in and click Sanitize, the tool scans for secrets using regex patterns and replaces each one with a numbered placeholder:

DB_HOST = "192.168.50.100"     →    DB_HOST = "{{IP_1}}"
DB_PASSWORD = "SuperSecret123" →    DB_PASSWORD = "{{PASSWORD_1}}"
API_KEY = "sk-test-abc123..."  →    API_KEY = "{{OPENAI_KEY_1}}"

A registry is built in the background mapping every placeholder to its real value. You copy the sanitized code, paste it into Claude or ChatGPT, and ask your question. When the AI responds with suggestions that reference {{IP_1}}, you paste that response back into the Restore tab. The tool looks up the registry and swaps every placeholder back to the real value before you see it.

The registry persists in localStorage so it survives a page refresh. If you sanitize three different code files in one session, the same IP always gets the same placeholder, and all three can be restored from the same registry.

What it detects automatically:

Category	Examples
IPv4 / CIDR	`10.10.10.10`, `192.168.1.0/24`
IPv6	Full and compressed formats
AWS Keys	`AKIA...`, `AWS_SECRET_ACCESS_KEY`
OpenAI Keys	`sk-...`, `sk-proj-...`, `sk_test_...`
Anthropic Keys	`sk-ant-...`
GitHub Tokens	`ghp_...`, `gho_...`
GitLab Tokens	`glpat-...`
Slack Tokens	`xoxb-...`, `xoxp-...`
Bearer Tokens	`Authorization: Bearer ...`
Generic API Keys	`api_key = "..."`, `token: "..."`
JWT / Signing Keys	`jwt_signing_key = "..."`
Passwords (quoted)	`password = "secret"`
Passwords (unquoted)	`PASSWORD=Hello123`, `db_password=secret`
DB Connection Strings	`postgres://user:pass@host`
PEM Private Keys	`-----BEGIN PRIVATE KEY-----` blocks

Architecture — nothing leaves the browser:

This is built with React and Vite. There is no backend, no server, no API calls. The entire sanitize and restore logic runs client-side in the browser. Your secrets never travel anywhere — not even to a server I control. The patterns.js file holds all the detection regexes and sanitizer.js handles the replace and restore logic. Both are plain JavaScript, readable, and extendable.

codemask/
├── src/
│   ├── engine/
│   │   ├── patterns.js       ← detection regexes (add your own here)
│   │   └── sanitizer.js      ← sanitize + restore logic
│   ├── hooks/
│   │   ├── useRegistry.js    ← session state + localStorage persistence
│   │   └── useCopy.js        ← clipboard hook
│   ├── components/
│   │   ├── CodePanel.jsx     ← input/output panels
│   │   ├── RegistryTable.jsx ← secrets table with blur/reveal
│   │   └── ManualAdd.jsx     ← manual secret registration
│   └── App.jsx

Running it locally:

git clone https://github.com/shubham-singhS2/CodeMask.git
cd CodeMask
npm install
npm run dev
# Open http://localhost:5173

Or with Docker:

docker run -d -p 8080:80 shubhamsinghs2/codemask:latest
# Open http://localhost:8080

One thing worth mentioning: CIDR notation is handled properly. 192.168.1.0/24 becomes {{IP_1}}/24 not {{IP_1}} — the prefix is preserved so the AI still understands it is a network range, not just a host address.

Solution 2 — CodeMask Proxy

The problem with the UI tool for agent workflows:

When you use Cline or Claude Code, the agent reads your project files and sends them to the LLM API automatically. There is no paste step, so there is no place to intercept manually. By the time you see any output, your secrets have already been sent.

The fix is a proxy server.

What it is: A local Node.js/Express server that runs on localhost:8080 and acts as a drop-in replacement for any OpenAI-compatible LLM API endpoint.

You change one setting in your AI agent — point the base URL to localhost:8080 instead of api.openai.com or api.mistral.ai. The agent never knows the difference. Every request passes through the proxy first.

The complete flow:

AI Agent (Cline)
      │
      │  POST /v1/chat/completions
      │  { messages: [{ content: "DB=192.168.1.10 password=secret" }] }
      ▼
CodeMask Proxy (localhost:8080)
      │  scans all message content for secrets
      │  builds session registry
      │  replaces real values with placeholders
      │
      │  POST /v1/chat/completions  ← forwarded to real API
      │  { messages: [{ content: "DB={{IP_1}} password={{PASSWORD_1}}" }] }
      ▼
Real LLM API (Mistral / OpenAI / your org LLM)
      │
      │  response: "The config connects to {{IP_1}} using {{PASSWORD_1}}"
      ▼
CodeMask Proxy
      │  scans response for placeholders
      │  restores real values from session registry
      │
      │  response: "The config connects to 192.168.1.10 using secret"
      ▼
AI Agent — receives real values, works normally

Proof from a real test:

I asked Cline to explain a config.py file containing real IPs and passwords while the proxy was running. This is what the proxy logged as going to Mistral:

[VERIFY] ── What proxy sent to LLM ──────────────────
[read_file for 'config.py'] Result:
1 | DB_HOST = "{{IP_1}}"
2 | DB_PASSWORD = "{{PASSWORD_1}}"
3 | API_KEY = "{{OPENAI_KEY_1}}"
[VERIFY] ─────────────────────────────────────────────

Mistral never saw a single real value. Cline received the response with real values fully restored and worked normally.

Session management — in-memory with TTL:

The registry that maps {{IP_1}} back to 192.168.1.10 lives in server memory, not a database or file. Each agent gets a session (derived from its API key), and sessions expire automatically after 60 minutes of inactivity. A cleanup timer runs every 10 minutes. If the proxy restarts, sessions clear — which is intentional. There is no sensitive data persisted anywhere on disk.

// Each session holds:
{
  id: "auto-abc123",
  registry: [
    { placeholder: "{{IP_1}}", realValue: "192.168.1.10", type: "ip" },
    { placeholder: "{{PASSWORD_1}}", realValue: "secret", type: "pass" }
  ],
  counters: { ip: 1, key: 0, pass: 1 },
  lastUsed: Date.now(),
  expiresInSec: 3450
}

Streaming — the tricky part:

LLM APIs stream responses as Server-Sent Events (SSE). Each chunk is a small JSON object with a few tokens of content. The challenge: a placeholder like {{IP_1}} can arrive split across two chunks:

Chunk 1: "connect to {{IP"
Chunk 2: "_1}} and use port 5432"

Per-chunk restoration fails because neither chunk contains the complete placeholder. The fix: buffer the entire stream from the LLM, restore placeholders on the complete assembled text, then re-emit the restored content as fresh SSE chunks back to the agent. The agent gets a streaming response. The placeholders are restored correctly. Both requirements satisfied.

Running it:

git clone https://github.com/shubham-singhS2/codemask-proxy.git
cd codemask-proxy
npm install
cp .env.example .env
npm start
# Proxy running at http://localhost:8080

Or with Docker (recommended for daily use — runs in background, restarts on reboot):

docker run -d \
  --name codemask-proxy \
  --restart always \
  -p 8080:8080 \
  -e OPENAI_TARGET_URL=https://api.mistral.ai/v1 \
  shubhamsinghs2/codemask-proxy:latest

Configuring your agent (Cline example):

API Provider: OpenAI Compatible
Base URL:     http://localhost:8080
API Key:      your-real-api-key  ← forwarded transparently
Model:        mistral-small-latest

That is the entire setup. One config change and every request is protected.

Monitoring — endpoints and dashboard:

The proxy exposes management endpoints so you can inspect what is happening:

# Health + global stats
curl http://localhost:8080/status | jq

# Active sessions
curl http://localhost:8080/sessions | jq

# Full registry for one session (values partially masked in output)
curl http://localhost:8080/session/SESSION_ID | jq

# Last 50 requests
curl http://localhost:8080/logs | jq

# Clear a session
curl -X DELETE http://localhost:8080/session/SESSION_ID

There is also a browser dashboard at http://localhost:8080/dashboard showing stat cards, session table with expandable registry, and a request log — useful if you prefer a visual view over curl.

Provider compatibility:

Provider	Works	Notes
OpenAI	✅	Standard format
Mistral	✅	Verified with Cline
Anthropic	✅	`/v1/messages` route
Groq	✅	Set `OPENAI_TARGET_URL=https://api.groq.com/openai`
Ollama	✅	Set `OPENAI_TARGET_URL=http://localhost:11434`
Org / internal LLM	✅	Set `DISABLE_TLS_VERIFY=true` for self-signed certs
AWS Bedrock	❌	SigV4 auth not supported yet
Google Gemini	❌	Different format not supported yet

The self-signed certificate case:

If your organisation runs an internal LLM with a self-signed certificate, Node.js will refuse to connect by default. Rather than setting NODE_TLS_REJECT_UNAUTHORIZED=0 in your terminal every time, you can set it once in .env:

DISABLE_TLS_VERIFY=true

The proxy reads this at startup and sets the flag internally. You never have to think about it again.

Testing Without a Real API Key

Both tools can be tested completely without spending any API credits using a mock LLM server included in the proxy repo.

# Terminal 1 — start mock server (pretends to be Mistral/OpenAI)
node mock-llm.js

# Terminal 2 — start proxy pointing at mock
# Set OPENAI_TARGET_URL=http://localhost:9999 in .env
npm start

# Terminal 3 — send a test request
curl -s -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "x-api-key: fake-key" \
  -d '{
    "model": "gpt-4",
    "messages": [{
      "role": "user",
      "content": "DB=192.168.1.10 password=secret123 fix this"
    }]
  }' | jq

The mock server prints a security check for every request showing whether it received placeholders or real values:

🔍 Security Check:
   Placeholders found : ✅ YES
   Real IPs present   : ✅ NO
   Real passwords     : ✅ NO

How the Two Tools Relate

They solve the same problem at different layers and are designed to be used together.

	CodeMask UI	CodeMask Proxy
For	Manual AI chat (ChatGPT, Claude.ai)	AI coding agents (Cline, Claude Code)
Triggered by	You, manually	Agent requests, automatically
Storage	Browser localStorage	Server memory, TTL-based
Runs as	Static site (Nginx/Vercel)	Node.js process or Docker container
Setup	Open a URL	One docker run or npm start

Both use the same detection engine — patterns.js and sanitizer.js — which is the core logic shared between them.

What Is Next

Both projects are deployed and working. The UI version is running on a K3s cluster deployed via ArgoCD using a GitOps pipeline — GitHub Actions builds a Docker image, pushes to Docker Hub, updates the Kubernetes manifests repo, and ArgoCD syncs the cluster automatically. That deployment story is worth a separate post.

Both are open source:

CodeMask UI: github.com/shubham-singhS2/CodeMask
CodeMask Proxy: github.com/shubham-singhS2/codemask-proxy
Docker Hub (UI): hub.docker.com/r/shubhamsinghs2/codemask
Docker Hub (Proxy): hub.docker.com/r/shubhamsinghs2/codemask-proxy

If you use AI coding tools and have not thought about what goes into those prompts, it is worth spending ten minutes on. The proxy setup takes less time than that.

How to Set Up a Free Custom Domain Email with Zoho Mail, Cloudflare, and Your Own Domain

Shubham Singh — Sat, 01 Aug 2026 18:29:57 +0000

How to Set Up a Free Custom Domain Email with Zoho Mail, Cloudflare, and Your Own Domain

A custom email address like contact@yourdomain.com makes a huge difference when you are building a personal brand, portfolio, or freelance presence. It looks more professional than a free Gmail address, and it is surprisingly easy to set up using Zoho Mail’s free plan and your domain’s DNS.

In this guide, I will walk through the exact flow I used to create a professional email address on a custom domain, without paying for a traditional business email suite.

Important: This post uses placeholder values instead of real DNS records, IPs, or credentials. Replace the examples with the values Zoho shows for your own account.

What you will need

Before you begin, make sure you already have:

A domain name (for example, yourdomain.com)
DNS access in Cloudflare or your domain provider
A Zoho Mail account
A few minutes to add DNS records and wait for propagation

For this setup, I used:

Website hosting: Vercel
DNS: Cloudflare
Email provider: Zoho Mail

That combination works very well for a personal website or portfolio.

Why use Zoho Mail?

Zoho Mail is useful because it lets you create a professional email address using your own domain. On the free plan, Zoho supports a single domain with up to 5 users, 5 GB of storage per user, and web-only access. The free plan is available only in select data centers, so availability may vary by region.

For a personal website, that is usually more than enough.

The overall flow

Here is the setup in simple terms:

Buy a domain.
Sign up for Zoho Mail.
Add your existing domain.
Verify that you own the domain using a TXT record.
Add MX records so mail is delivered to Zoho.
Add SPF, DKIM, and DMARC for email authentication.
Test sending and receiving mail.

Step 1: Sign up for Zoho Mail

Go to Zoho Mail’s signup page and choose the free plan.

During signup, Zoho will ask whether you want to add a new domain or an existing one. Since you already own the domain, choose Add an existing domain.

Enter your domain exactly as it should appear, for example:

yourdomain.com

Do not type www.yourdomain.com for email setup. Email should be configured on the root domain.

Step 2: Verify domain ownership

Zoho will ask you to prove that you own the domain. The simplest method is to add a TXT record in Cloudflare DNS.

Zoho will give you a TXT value similar to this:

zoho-verification=zbXXXXXXXX.zmverify.zoho.in

In Cloudflare, add a new DNS record:

Type	Name	Content
TXT	@	`zoho-verification=zbXXXXXXXX.zmverify.zoho.in`

If Cloudflare does not accept @, use the root domain name directly.

After saving the record, go back to Zoho and click Verify TXT Record.

Once that works, Zoho knows the domain belongs to you.

Step 3: Create your mailbox

After verification, Zoho will let you create the first user account for your domain.

For a personal site, a good choice is:

contact@yourdomain.com

You can also create:

hello@yourdomain.com
shubham@yourdomain.com
resume@yourdomain.com
jobs@yourdomain.com

If you only want one inbox, use aliases later instead of creating multiple mailboxes.

Step 4: Add MX records in Cloudflare

MX records tell the internet where your email should be delivered.

Without MX records, people can send mail to your domain name, but no one will know which server should receive it.

Add the MX records Zoho provides for your data center. For Zoho’s India region, the records usually look like this:

Type	Name	Mail Server	Priority
MX	@	mx.zoho.in	10
MX	@	mx2.zoho.in	20
MX	@	mx3.zoho.in	50

In Cloudflare DNS:

Type: MX
Name: @
Content: mx.zoho.in / mx2.zoho.in / mx3.zoho.in
Priority: 10, 20, 50

Do not proxy MX records. Cloudflare handles them as DNS-only records.

Step 5: Add SPF

SPF tells the world which servers are allowed to send email for your domain.

Add this TXT record:

v=spf1 include:zoho.in ~all

In Cloudflare:

Type	Name	Content
TXT	@	`v=spf1 include:zoho.in ~all`

What SPF means

This says:

Zoho is allowed to send mail for your domain.
Other servers should not be trusted by default.

This helps reduce spoofing and improves inbox delivery.

Step 6: Add DKIM

DKIM adds a digital signature to outgoing email. It helps receivers confirm that the message really came from your domain and was not modified in transit.

Zoho will generate a DKIM public key for you. The record usually looks like this:

Type	Name	Content
TXT	zmail._domainkey	`v=DKIM1; k=rsa; p=YOUR_LONG_PUBLIC_KEY_HERE`

What to do

Open Zoho Admin Console.
Go to DKIM settings.
Generate the DKIM record.
Copy the full TXT value into Cloudflare.
Save the record.
Return to Zoho and verify it.

DKIM verification can take a little longer than SPF because DNS propagation and verification caches may not update instantly.

Step 7: Add DMARC

DMARC is the policy layer that sits on top of SPF and DKIM.

It tells receiving mail servers what to do when authentication fails.

A good starting DMARC record for a personal domain is:

v=DMARC1; p=quarantine; pct=100; adkim=r; aspf=r; rua=mailto:contact@yourdomain.com; ruf=mailto:contact@yourdomain.com

In Cloudflare:

Type	Name	Content
TXT	_dmarc	`v=DMARC1; p=quarantine; pct=100; adkim=r; aspf=r; rua=mailto:contact@yourdomain.com; ruf=mailto:contact@yourdomain.com`

What these parts mean

p=quarantine → suspicious messages should go to spam
pct=100 → apply this policy to all mail
adkim=r → relaxed DKIM alignment
aspf=r → relaxed SPF alignment
rua → aggregate reports
ruf → forensic reports

For most personal domains, relaxed alignment is the simplest and safest choice.

Step 8: Wait for propagation

After you add the records, the changes need time to spread across DNS resolvers.

Usually:

TXT records propagate quickly
MX records may take a little longer
Zoho’s dashboard may still show red or pending status even when everything is already working

Do not panic if Zoho’s UI is slow to update.

A good way to confirm is to test real mail flow.

Step 9: Test sending and receiving

Send a test email from your Zoho mailbox to Gmail.

Then reply from Gmail back to your custom domain email.

If both directions work, the setup is operational.

You can also check the message headers in Gmail to confirm:

SPF: pass
DKIM: pass
DMARC: pass

That is the best real-world proof that your setup is correct.

Common issues and fixes

1. Zoho still shows MX in red

If mail is already working, the DNS is usually fine. Wait for propagation and check again later.

2. SPF is green but DKIM is still pending

That usually means the DKIM TXT record is correct but Zoho has not rechecked it yet, or the record was added recently.

3. Email is landing in spam

Check all three:

SPF
DKIM
DMARC

Also make sure your domain is not sending from an unauthorized service.

4. Cloudflare says the record already exists

Double-check for duplicates. You should have only one SPF TXT record and one DKIM TXT record for each selector.

Optional improvements

Once the core setup works, you can make it even better:

Create aliases

A single inbox can receive mail for multiple addresses such as:

contact@yourdomain.com
hello@yourdomain.com
resume@yourdomain.com
jobs@yourdomain.com

Add a signature

A clean signature makes every email look more professional:

Shubham Singh
DevOps / DevSecOps Engineer

Website: https://yourdomain.com
LinkedIn: linkedin.com/in/your-link
GitHub: github.com/your-handle
Email: contact@yourdomain.com

Use your custom email everywhere

Replace your Gmail address on:

Portfolio website
Resume
LinkedIn contact info
Job applications
GitHub profile
Freelance profiles

That keeps your brand consistent.

What this setup gives you

This setup is not end-to-end encrypted email, but it does give you:

Professional custom email
TLS encryption in transit
SPF authentication
DKIM signatures
DMARC protection
Better inbox deliverability
A clean personal brand

For a portfolio or professional website, this is exactly what you want.

Final DNS record checklist

Here is the full checklist in one place:

Record	Purpose	Example
TXT	Zoho domain verification	`zoho-verification=zbXXXXXXXX.zmverify.zoho.in`
MX	Incoming mail delivery	`mx.zoho.in`, `mx2.zoho.in`, `mx3.zoho.in`
TXT	SPF	`v=spf1 include:zoho.in ~all`
TXT	DKIM	`v=DKIM1; k=rsa; p=...`
TXT	DMARC	`v=DMARC1; p=quarantine; ...`

Conclusion

With a domain, Cloudflare DNS, and Zoho Mail’s free plan, you can build a fully professional email address without paying for a large business email suite.

For a personal portfolio, that is one of the best low-cost upgrades you can make.

It improves your credibility, looks cleaner on your website, and gives your project a more polished finish.