Forem: Mohit Kumar Kushwaha

pmcli: local cli for managing those forgetful passwords

Mohit Kumar Kushwaha — Sat, 25 Apr 2026 20:45:51 +0000

a Local CLI Password Manager in Python

I have been working on a small local password manager called PMCLI.

The goal is simple: store credentials locally, encrypt the saved passwords, and retrieve them from the terminal without printing secrets directly to the screen.

GitHub repo:

https://github.com/KimtVak8143/pmcli

This is not meant to replace a production password manager like 1Password or Bitwarden. It is a learning project for building a secure-ish CLI tool with clean Python structure.

Tech Stack

Python
Typer for the CLI
cryptography for encryption
Fernet for symmetric encryption
PBKDF2 for deriving an encryption key from a phrase
pyperclip for copying passwords to the clipboard
JSON file storage

The vault is stored locally at:

~/.pmcli/vault.json

Basic Usage

After setup, the tool can be used like this:

pmcli add github.com
pmcli list
pmcli get github.com
pmcli reveal github.com

The get command shows only the username.

The reveal command does not print the password. It copies the password to the clipboard.

Project Structure

I split the app into small modules:

pmcli/
├── main.py
├── crypto.py
├── storage.py
├── commands/
│   ├── add.py
│   ├── get.py
│   ├── reveal.py
│   ├── list_cmd.py
│   └── config.py
└── README.md

The separation is intentional:

main.py only registers commands
commands/ contains CLI behavior
crypto.py handles encryption and decryption
storage.py handles reading and writing the vault

This made the code easier to reason about as the project grew.

Encryption Design

One important design change was separating the master password from the encryption phrase.

At first, the master password was used directly for encryption and decryption. That worked, but it had a problem:

if the master password changed, all existing passwords became unreadable.

So I changed the design:

PMCLI_MASTER_PASSWORD=used to unlock reveal
PMCLI_ENCRYPTION_PHRASE=used to encrypt and decrypt stored passwords

The master password is now used only as an access check before revealing a password.

The encryption phrase is the stable secret used for encryption.

That means the master password can be changed without breaking the vault, as long as the encryption phrase stays the same.

Adding a Credential

The add command:

asks for a username
asks for the password
validates empty input
prevents accidental overwrite
encrypts the password
saves it in the vault

The saved JSON looks roughly like this:

{
  "github.com": {
    "username": "user@example.com",
    "password": "gAAAAAB..."
  }
}

The password value is encrypted before it is written to disk.

Revealing a Password

The reveal command:

checks if the site exists
asks for the master password
validates it against the configured master password
decrypts using the encryption phrase
copies the password to the clipboard

It intentionally does not print the password.

That small behavior matters. Terminal history, screen sharing, and logs are all easy ways to accidentally leak secrets.

Configuration

The local config lives in .env:

PMCLI_MASTER_PASSWORD=your-reveal-password
PMCLI_ENCRYPTION_PHRASE=your-stable-encryption-phrase

The real .env file is ignored by git.

Only .env.example is committed.

Things I Learned

Some useful lessons from this project:

Keep CLI routing separate from business logic
Do not print secrets if copying to clipboard is enough
Never commit local secret config
Think carefully before tying encryption to a changeable password
Small command files are easier to test and modify

Final Thoughts

This was a fun project because it sits at the intersection of CLI design, encryption, local storage, and security tradeoffs.

Even a small password manager forces you to think carefully about defaults:

What should be printed?
What should be stored?
What should be ignored by git?
What happens when a user changes a secret?

The code is small, but the design decisions are real.

That is what made this project worth building.

You can find the code here:

https://github.com/KimtVak8143/pmcli

HelloDev - Scrum powered by Notion

Mohit Kumar Kushwaha — Wed, 25 Mar 2026 17:29:17 +0000

This is a submission for the Notion MCP Challenge

HelloDev — The Sprint Tracker That Runs Itself

No standups. No manual updates. Just ship.

What I Built

HelloDev is an agentic sprint tracking system built for the modern SDLC — one where developers shouldn't have to touch a project management tool to keep it accurate.

The core idea: a developer runs hellodev start bug-#3 --dev Alice, writes code, commits, and runs hellodev done bug-#3. That's it. Everything else — Notion updates, activity logs, time tracking, commit counts — happens automatically in the background.

The Problem It Solves

Engineering teams waste real hours each week on ritual updates:

Moving Jira/Notion cards manually
Writing standup messages nobody reads
Copy-pasting commit summaries into ticket comments

HelloDev eliminates this entirely by treating the developer's actual workflow (git commits, coding sessions, CLI commands) as the source of truth — and syncing it directly to Notion.

Architecture

Developer Machine
│
├── hellodev CLI           → POST /start, /done, /status
├── Git post-commit hook   → POST /commit (auto, no dev action)
└── VSCode Copilot Chat    → MCP tools (list_tasks, start_task, etc.)
        │
        ▼
Express Server (localhost:3333)
        │
        ├── Session Manager    (in-memory, single active task)
        ├── Timer + Idle Det.  (5-min idle threshold)
        └── Notion Client      (@notionhq/client v2.2.15)
                │
                ▼
        Notion Workspace
        ├── Sprint Board       (task lifecycle: Todo → In Progress → Done)
        ├── Activity Logs      (per-session: time, commits, lines changed)
        └── Developers         (team registry)

Key design decisions:

MCP server uses stdio transport — runs as a subprocess in VSCode, zero network config
MCP tools proxy to Express via axios — clean separation of concerns
@notionhq/client pinned to v2.2.15 — v5.x has breaking API changes, stay pinned
CommonJS throughout (no TypeScript) — faster iteration, simpler deployment
Git hook is pure bash + curl — no Node dependency in the hook itself

What It Tracks Automatically

Every session captures:

Metric	Source
Session start / end time	Timer module
Total hours coded	Idle-aware timer
Commit count	Git hook → POST /commit
Commit messages	Git hook (pipe-separated)
Files changed	`git diff --stat` in hook
Lines added / removed	`git diff --numstat` in hook

All of this lands in a linked Activity Log entry in Notion, related back to the Sprint Board task.

Video Demo

Show us the code

🔗 GitHub: github.com/KimtVak8143/HelloDev

How I Used Notion MCP

Notion MCP is the backbone of HelloDev's intelligence layer — specifically what makes it agentic rather than just a logging tool.

The Integration

HelloDev uses two separate MCP surfaces:

HelloDev MCP Server (custom, stdio):
Runs as a subprocess in VSCode via mcp.json. Exposes 5 tools to GitHub Copilot Chat:

Tool	What it does
`list_tasks`	Pulls pending Sprint Board tasks for a developer
`start_task`	Marks task In Progress in Notion + starts timer
`complete_task`	Marks Done, seals the Activity Log
`get_status`	Returns live session: elapsed time + commits
`get_sprint`	Full sprint board overview

This means a developer can type in Copilot Chat: "What tasks do I have this sprint?" and get a live Notion query — no context switching, no browser tab.

Direct Notion API via @notionhq/client :
Under the hood, every MCP tool call hits the Express server, which calls Notion directly.

What Notion MCP Unlocks

Without MCP, HelloDev would be a CLI tool that talks to Notion. Useful, but closed. With MCP:

Copilot Chat becomes a sprint interface — ask questions, get Notion data, trigger actions — all from the editor
The system is composable — future AI agents can call list_tasks or get_sprint as part of larger automated workflows
Zero context switching — the developer's entire sprint lives inside their coding environment

The real unlock is that Notion stops being a destination you visit and becomes a data layer your tools read and write automatically.

What's Next — Auto Standup Report delivered to your inbox

The next phase generates a daily Notion page at EOD — summarizing every developer's activity from the last 24 hours:

Tasks completed
Total hours coded
Commits made
Active blockers (tasks still In Progress)

No meeting. No Slack message. Just open Notion Monday morning.

Built with Node.js · Express · Notion API · MCP SDK · Git hooks

🚀 What's Further Ahead — VSCode Extension

The natural evolution of HelloDev is a first-class VSCode Extension —
eliminating even the CLI and making sprint tracking truly invisible to the developer.

What the Extension Would Do

Auto-detect the active git repo and developer identity
Show a status bar item: ⏱ bug-#3 — 1h 24m — 3 commits
Trigger start/done via the Command Palette (Ctrl+Shift+P → HelloDev: Start Task)
Surface pending sprint tasks in a dedicated sidebar panel (TreeView)
Replace the git hook with a native VSCode workspace.onDidSaveTextDocument listener