DEV Community: S. Afsan

How I Manage All My Claude Code Sessions from a Single Terminal

S. Afsan — Wed, 03 Jun 2026 06:37:01 +0000

I run multiple Claude Code sessions all day — one per feature, one per service, sometimes five at once.

Every session was asking me for permission in its own terminal. I'd miss requests buried in a background tab. I'd switch windows mid-thought just to approve a git status. I'd lose context constantly.

And there was no single place to see what Claude was doing across all of them.

So I built Gatekeeper — a TUI daemon that intercepts every Claude Code tool call and routes it to one unified approval dashboard.

The dashboard

Three panes, one terminal:

Left — all active Claude sessions, with status badges: [auto] means auto-approve is on, [linked] means it's wired to a terminal window
Middle — pending permission requests with an age timer so you know what's been waiting longest
Right — full request detail, danger warnings, and the numbered approval menu

Every Claude Code tool call — Bash, Edit, Write, Agent — passes through a PreToolUse hook before executing. The hook connects to Gatekeeper's Unix socket, sends the request, and blocks. Gatekeeper shows it in the UI. When you decide, the answer travels back and Claude proceeds or stops.

Approving requests

The menu in the right pane mirrors Claude Code's own style:

1  Allow once
2  Always allow
3  Deny

↑/↓ moves the cursor, Enter confirms. Or just press 1, 2, 3 directly. A and D are quick shortcuts for allow/deny.

Option 2 — always allow — is where it gets useful. Choosing it saves a persistent rule so the same request never surfaces again:

Bash → saves the command pattern (e.g. npm run *) to config
Edit / Write → saves the directory to an allowlist
Agent → enables auto-approve for that session

The rule is written both to Gatekeeper's own config and to Claude Code's settings.json allowlist — so Claude Code itself won't prompt for it either.

Auto-approve sessions

Press A in the Sessions pane to mark a session as trusted. It shows [auto] — routine tool calls pass silently without appearing in the queue.

But some things always require manual approval, no matter what:

Category	What's blocked
File deletion	`rm`, `rmdir`, `shred`
Remote access	`ssh`, `scp`, `rsync`
Privilege escalation	`sudo`, `su`
Destructive git	`push --force`, `reset --hard`, `clean -f`
Infrastructure	`terraform apply/destroy`, `kubectl delete`
Sensitive paths	Writes to `/etc/`, `~/.ssh/`, `~/.aws/`

Read-only commands — grep, find, ls, cat, git status, npm install — always pass through freely.

Linking sessions to terminals

This is the feature that unlocks everything else.

Press L on any session in the Sessions pane. An overlay appears — switch to the Claude terminal tab (alt+tab, click, whatever), and Gatekeeper detects the focus change and links that session to that window automatically. The session shows [linked].

Links persist across restarts in ~/.claude/perm-window-map.json. You link once, it stays.

Sending messages from Gatekeeper

Once a session is linked, press M, type your message, press Enter.

Gatekeeper injects the text into the linked Claude terminal using X11 XTEST — it appears and submits automatically, exactly as if you typed it and pressed Enter there. You never leave the Gatekeeper terminal.

This solves a problem I didn't know I had until I built it: Claude pauses mid-task and asks a clarifying question — A / B / C?. Normally you'd switch to that terminal, answer, switch back. With Gatekeeper, you just press M and type from wherever you are.

Useful for:

Answering Claude's mid-task questions without switching windows
Explaining why you denied a request
Redirecting Claude to a different approach while it waits

One caveat: injection works when each Claude session is in its own terminal window. If multiple sessions share one window as tabs, they share the same X11 window ID — Gatekeeper can't target a specific tab. Run each session in a new window (kitty, gnome-terminal --window, etc.).

Settings

Press S to open the settings panel. From here you can configure:

Tool types — which tools (Bash, Edit, Write, Agent) Gatekeeper intercepts
Bash categories — how commands are classified (read-only vs. destructive vs. network, etc.)
Custom patterns — your own allow/deny rules beyond the defaults

No config file spelunking. Everything is editable from inside the dashboard.

Stats

gatekeeper stats        # today
gatekeeper stats 7      # last 7 days
gatekeeper stats all    # all time

====================================================
 GATEKEEPER STATS
====================================================
  Total decisions : 177
  Auto-approved   :  16  (  9%)
  Manual reviewed : 161  ( 90%)
    allowed       : 161
    denied        :   0

  Auto-approved by session:
    b73f7ccc    7 calls
    a8ed1d57    5 calls

  Auto-approved by tool:
    Bash          11
    Edit           5
====================================================

Every decision is logged to ~/.claude/perm-logs/YYYY-MM-DD.log, one file per day, kept indefinitely. Useful for auditing what Claude did across a long session or a whole project.

What happens when Gatekeeper isn't running

The hook falls back to a Y/n prompt in the Claude terminal with a 30-second auto-deny. Nothing hangs, nothing silently passes. You can also set GATEKEEPER_TIMEOUT=0 to always use the terminal prompt for a specific session.

How it's wired up

install.sh does four things:

Installs wrapper scripts in ~/.claude/bin/
Registers the PreToolUse hook in ~/.claude/settings.json
Adds blanket permissions.allow rules so Claude Code doesn't double-prompt
Sets permissions.defaultMode = "bypassPermissions" — disables Claude Code's built-in dialogs entirely, making Gatekeeper the sole approval gate

That last point matters: Claude Code's own hardcoded prompts for sensitive paths (/proc/, /sys/, ~/.bashrc) are suppressed in bypassPermissions mode. Gatekeeper handles everything instead.

Installation

git clone https://github.com/Btocode/gatekeeper
cd gatekeeper
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
bash install.sh

Then open a dedicated terminal and run:

gatekeeper

Start your Claude Code sessions anywhere — other terminals, VS Code, JetBrains. Every tool call will appear in Gatekeeper.

Requirements: Linux + X11 + Python 3.11+

Why I built this

I was working on a project with five Claude sessions running in parallel — one per subsystem. Each one was capable. But I was the bottleneck: constantly switching windows to approve npm run build for the fifth time that hour.

Gatekeeper changed that. Trusted sessions handle routine calls without interrupting me. Anything new or risky surfaces in the dashboard. I answer Claude's questions without leaving my main terminal. And at the end of the day, gatekeeper stats tells me exactly what happened.

It's open source. MIT licensed.

👉 github.com/Btocode/gatekeeper

If you run Claude Code with multiple sessions, give it a try. And if you build tools like this — follow me, more coming.

Tags: claudecode ai devtools opensource

How to set up DKIM for Zoho Mail

S. Afsan — Wed, 13 May 2026 04:10:26 +0000

Originally published on mailermonk.com. Cross-posted here for reach — the canonical version lives on MailerMonk.

About this guide

Zoho Mail is a budget-friendly business mail platform. The DKIM step is unusual — you generate the selector inside the Zoho admin console rather than using a fixed name.

DKIM (DomainKeys Identified Mail, RFC 6376) is the cryptographic signature attached to outgoing email so receivers can verify the message wasn't tampered with and that it actually came from a server authorized by your domain. To turn it on for Zoho Mail, you publish one or more DNS records at <selector>._domainkey.<your-domain> containing the public key matching the private key Zoho Mail uses to sign.

Most ESPs (including Zoho Mail) ask you to publish CNAME records that point at hosted keys they manage. This is preferable to publishing the raw key text yourself — when the provider rotates keys, your DNS keeps pointing to the rotated key and nothing breaks.

Publish these DNS records

Add the following record(s) to your domain's DNS zone. Most registrars (Cloudflare, Route 53, Namecheap, GoDaddy) accept values exactly as shown.

Host:  <your-selector>._domainkey
Type:  TXT
Value: v=DKIM1; k=rsa; p=<KEY_FROM_ZOHO>

Why this matters

Zoho asks you to choose a selector when generating the key in the Mail Admin Console (https://mailadmin.zoho.com → Domains → your domain → Email Configuration → DKIM). zoho is the conventional choice; once chosen, the selector is fixed for that key.
Zoho generates 2048-bit keys. The TXT value will exceed the 255-character single-string limit; most DNS providers (Cloudflare, Route 53, Namecheap, GoDaddy) split this automatically when pasting. If your provider does not, wrap the value as multiple quoted strings concatenated: "v=DKIM1; k=rsa; p=MIIBIj..." "...rest".
After the TXT record propagates, return to the Zoho admin console and click Verify. Only after Zoho validates the record will the Enable DKIM button appear — publishing DNS alone does not turn on signing.

Where in Zoho Mail

The DKIM configuration lives in Zoho Mail Admin → Domains → <your-domain> → Email Configuration → DKIM.

Verify the records

After the records propagate, run the DKIM Checker against your domain with each selector to confirm the public key resolves and parses correctly.

dig +short TXT <selector>._domainkey.your-domain.com

Common pitfalls

Zoho's DKIM verification step takes 30–60 minutes to recognize a freshly published TXT record even when DNS has propagated globally. Hitting the Verify button repeatedly does not help — wait it out and try again after an hour.
If you migrate from Google Workspace to Zoho, remove Google's _domainkey records during cutover or you'll have multiple DKIM selectors active and may get flagged as spoofing.
EU and US Zoho accounts use different DNS hosts. include:zoho.com is for global/US; EU customers must use include:zohomail.eu. The DKIM record is generated regardless, but the SPF mismatch will fail alignment for some receivers (especially Outlook.com and Yahoo EU).
The Zoho admin console occasionally shows the TXT value truncated in the UI. Always copy from the Copy button rather than selecting text manually — manual selection often misses the trailing characters of the public key.

Frequently asked questions

What selector should I use for Zoho Mail DKIM?

Zoho lets you choose any selector name when generating the key, but zoho is the de-facto standard and the one Zoho's own documentation uses in examples. Once you generate the key with a given selector, the selector is fixed for that key — to change it, generate a new key with the new selector and publish a second TXT record. You can run two selectors in parallel during a rotation without breaking anything.

Where do I find the DKIM key value in Zoho?

Sign in at https://mailadmin.zoho.com as an admin or super-admin → Domains (left menu) → click the domain you're configuring → Email Configuration → DKIM. Click Add Selector, choose a name (e.g. zoho), and Zoho generates the public-key TXT value. Copy it with the Copy button — do not select the text manually as the UI sometimes truncates trailing characters.

Why does Zoho's Verify button say the DKIM record is missing when `dig` shows it's published?

Zoho's verification probes a non-authoritative resolver that lags 30–60 minutes behind public DNS propagation. If dig +short TXT zoho._domainkey.your-domain.com from a public resolver (1.1.1.1, 8.8.8.8) returns the record, the record is live — just wait an hour and click Verify again. There's nothing wrong with your DNS.

Can I use Zoho Mail's DKIM with another provider's SPF and DMARC?

Yes — DKIM, SPF, and DMARC are independent. You can sign outbound Zoho mail with DKIM while your SPF record includes multiple senders (Zoho + your CRM + your marketing tool) and your single _dmarc record covers them all. DKIM alignment only requires that the d= tag in the DKIM signature matches the From: header domain, which Zoho handles when you authenticate your domain.

My Zoho DKIM key is over 255 characters — how do I publish it?

DNS TXT records have a 255-character per-string limit, but a single TXT record can contain multiple quoted strings concatenated. Modern DNS providers (Cloudflare, Route 53, Namecheap, GoDaddy, Google Domains) handle this automatically — paste the full key as one value and they split it. For older providers that don't auto-split, manually wrap it: "v=DKIM1; k=rsa; p=MIIBIj...first-255-chars" "...rest-of-key". Receivers reassemble the strings before parsing.

How long does it take for Zoho DKIM to start working?

Once you publish the TXT record, allow up to an hour for DNS propagation to Zoho's verification probe. After Zoho's Verify succeeds and you click Enable DKIM, signing starts on the next outbound message — there is no further delay. Receivers cache DKIM keys briefly (typically 5–15 minutes), so the first message may not verify at every receiver immediately but should be clean within 30 minutes.

Do I need to enable DKIM in Zoho even after the DNS record is verified?

Yes — verification only confirms the public key is reachable. You must explicitly click Enable DKIM for that selector in the Zoho admin console for Zoho to start signing outbound mail with the matching private key. Until you flip the switch, the TXT record exists but no signatures are produced, and DMARC will fail DKIM alignment.

Want continuous monitoring instead of one-shot DNS checks? MailerMonk watches your DKIM record, aggregate DMARC reports, and inbox placement — and pings you the moment something drifts. Free for the first domain.