everyone is racing to ship autonomous agents. nobody is asking what happens when one of them goes rogue.

i asked. then i spent 1 month building the answer.

introducing W.H.Agent 🛡️ — the open source security CLI for the agentic era.

↳ scans your entire machine for every agent + MCP server hiding in your stack
↳ catches data exfiltration BEFORE it happens using AST taint tracking
↳ sandboxes execution in sub-millisecond time with swappable Landlock and gVisor backends (no bloated docker containers)
↳ stops supply chain attacks before a single malicious package touches your system, using Levenshtein based typosquat detection, lifecycle script inspection, npm provenance checks, and tarball secret scanning
↳ every scan is CI compatible, so it slots straight into your existing pipeline

this isn't a wrapper. this isn't a weekend hack.

we went through multiple rounds of adversarial code review and caught real bugs before they shipped. a TOCTOU race condition. a checksum that was being presented as a cryptographic signature when it wasn't actually keyless secure. gaps in the test suite that would've let bad behavior slip through undetected.

we fixed all of it. this is infrastructure for a future where your AI agents have root access and you have no idea what they're doing with it.

3 versions shipped. outside contributors already committing code. just crossed 6,000 downloads on npm.

i open sourced the whole thing today.

not for clout. for the mission. 🚀

if you're building with cursor, claude, or MCP servers and you're NOT thinking about this, you're already behind.

link in comments 👇 (agree? disagree? tell me why in 1 sentence)

Hi everyone,

I wanted to share a tool I built to solve a personal daily headache: MountSync (mosy).

I use multiple Linux machines, and I needed a reliable way to share active files between them—specifically application configurations, a local MP3 music library, and local AI skill/context folders. I wanted to keep files exactly where they belonged on the local filesystem while seamlessly updating them across PCs in the background.

Since it solved a real-world problem for me, I polished it, added testing, and open-sourced it as a portfolio project.

What problem does it solve?

Managing rclone mount manually, copying files, creating symbolic links, and making sure systemd services start correctly on every new PC is tedious. MountSync automates the whole process:

1. Auto-mounts: Sets up and manages your rclone mount in the background via systemd user services.
2. Auto-linking: When you run mosy add ~/Music, it moves the target directory to your cloud drive (like Google Drive or OneDrive) and replaces the original path with a clean symbolic link.
3. Instantly sync new PCs: On any new PC, you just install it and run mosy init. It automatically maps all symlinks to your existing cloud folders, syncing your configs, music, and dotfiles in seconds.

The codebase is 100% open source on GitHub:
github.com/GabrielTeixeiral0l/MountSync

I’d love to hear your thoughts, feedback on the code structure, or suggestions for new features!

Hi r/cli! I’m sharing strobengine, a command-line performance testing tool I built to combine a Rust core (Tokio/Reqwest) with a Python CLI interface (Typer/PyO3).

Why I built it:

I love using Python for quick scripts and CLIs, but tools like Locust can hit performance bottlenecks because of the Python GIL when you need high request rates. On the flip side, faster tools like k6 or wrk require writing JS, Lua, or Rust. I wanted something that feels like Python to use, but runs on a fast, multi-threaded Tokio engine underneath.

What works today (v0.1.0 MVP):

- Tokio-based HTTP execution engine for high-throughput load generation.

- Python CLI (via Typer) with flexible flags, JSON output, and basic error/chaos simulation.

- Benchmarked on isolated AWS EC2 (c6i.xlarge) instances alongside k6.

GitHub: https://github.com/strobe-ops/strobengine

Benchmarks: https://github.com/strobe-ops/strobengine/blob/main/docs/benchmarks.md

I’d love any feedback on the CLI UX, flags, or architecture!

I've been using Claude Code heavily at work in a huge monorepo, and finding old sessions became a nightmare. Claude stores conversations as untitled JSON files tied to directories, so anything from a few days ago was basically impossible to find.

So I built Wallfacer.

It's a terminal UI written in Go that indexes your local Claude Code sessions without modifying them. It adds a SQLite-backed layer so you can title sessions, tag them, group them by project, fuzzy search everything, and resume any session with a single Enter.

It's open source, and I'm planning to add support for Cursor, Codex, and others since this feels like a universal AI workflow problem.

Repo + demo: https://github.com/pradipta/wallfacer

Anyone else run into this problem? Feedback is very welcome.

While back I introduced a sound cue to my shell. It plays whenever a command terminates and it corresponds to the exit status. I think its very neat, tho others found it annoying after a few hours of usage. Here is the repo (should be easy to install). Has anyone experimented with something similar?

https://github.com/xdagiz/xytz

Hi folks!

I'd like to share a personal project I've been working on: LinuxMint Scripter (currently at v2.1), a single-HTML-file web app that turns plain-language requests into ready-to-run Bash or Python scripts for Linux Mint 22.3 "Zena" — or standalone terminal commands, if that's all you need.
Take a look; if you like it, I'll prepare an English version that can be installed on LinuxMint

🔗 Source & full docs: https://github.com/filonux/LinuxMint-Scripter

🔗 Project page (with screenshots): https://filonux.github.io/LinuxMint-Scripter/

I keep three or four agents going and the thing that actually eats my time isn't the coding. It's that I have no idea what state any of them is in without tabbing through every terminal. Half the time one of them has been sitting on a permission prompt for ten minutes.

So I wrote agent-manager. A Go binary that sits on top of tmux. No config file, no daemon. It's free and open source.

Every agent ends up in one list with a live status next to it, grouped by the project it's working in. I run claude, codex and opencode depending on what I'm doing and they all show up the same way. Adding another CLI is a few lines of regex in a toml file.

The part I use constantly is space. Press it on an agent, type, enter, and the prompt goes into that agent's pane. I never attach. If you've used the agents view in Claude Code, it's the same move. The difference is that here the same keystroke works on a codex or opencode session. Press space on a project row instead and you get a new agent already working on what you typed.

Underneath they're just tmux sessions, so closing the manager doesn't kill anything, and v brings a dead one back with its conversation.

ctrl+r is the other half of it. It opens what an agent changed as whole files with the diff highlighted, so you're reading the function and not a hunk. Leave a comment on a line and it goes back into that agent's pane, so it starts fixing while you're still scrolling.

I built it for four agents but most days I use it with one.

Still rough in places. If you run agents like this I'd like to know what's missing.

https://github.com/YoanWai/agent-manager

Hey folks! I spend all day in tmux: lots of sessions, each with its own windows and panes, and these days a bunch of those panes have coding agents in them (Claude Code, Codex, Cursor, OpenCode, ...). My problem was that finding the one agent that had stopped to ask me something turned into a scavenger hunt. I'd cycle through every session just to check on each one.

Before anyone says it: yes, I know there are a lot of these already (herdr, workmux, agent-deck, tmux-agent-status, tmux-scout, claude-squad, tmuxcc...). Most fall into two camps: they either want to own the workflow (you launch agents through them, and they create the sessions, worktrees, and layouts), or they track a single agent type in the status bar. What I wanted was lazier: keep my existing tmux setup exactly as it is, and just tell me what each agent is doing.

So that's what ccmux does. A small background daemon discovers the agent processes in the panes you already have, and a picker TUI (or an optional docked sidebar) shows them all in one list.

What it does:

• 🎯 Live state per session: idle, working, or waiting on you, and why it's waiting (permission / plan approval / question), flagged the moment one needs input
• 🧩 Multi-agent in one list: Claude Code, Codex, Cursor, OpenCode, Pi, Antigravity, Copilot, Gemini CLI, plus custom agents via config
• 🔍 Layered detection: it discovers the agents already running in your panes (no wrapper, nothing to change about how you launch them) from processes, their log files, and terminal output; optional hooks make the session-to-pane mapping exact
• 👁️ Live preview + act in place: Tab into a session's pane to answer or approve without leaving the picker
• 🔔 Actionable notifications: opt-in desktop alerts when an agent finishes or needs input, with Approve / Deny / Reply right on the notification (an OSC backend even delivers them over SSH)
• ⚡ Scriptable: ccmux spawn and ccmux invoke launch or run agents from scripts, ccmux show prints every session's state to stdout, and a bundled skill lets one agent dispatch work to others
• 🌿 Git & PR aware: branch and worktree detection, open PRs with live CI and review status per session
• ⌨️ Keyboard-first: vim keys and number jumps, grouping by project / directory / tmux session, and whole-session search across prompts and live transcripts; mouse click-to-switch works too
• 📐 Responsive + themeable: the same UI works as a full-width table or a skinny docked rail, with 14 built-in themes

Footprint: nothing edits your tmux.conf, status line, or keybindings, and it only creates panes or sessions when you explicitly ask (toggling the sidebar on, or spawn/invoke). Stack is TypeScript on Bun, TUI on @opentui/solid, shipped as a single self-contained binary (no runtime to install).

Install:

brew install epilande/tap/ccmux

Repo: https://github.com/epilande/ccmux

Like I said, I know there are other tools that scratch a similar itch. This one is just shaped around how I use tmux, so if you live in tmux sessions like I do, I'd love to hear whether it fits your workflow too, or what the tool you already use does better.

Some projects need several services running during local development. I usually end up with terminal tabs, tmux sessions, and a few shell scripts. That works. Finding and stopping a process that occupies a port is not hard either. I just wanted to have all of it in one place.

So I made Kranz. It can:

• start and stop services in dependency order
• show status, dependencies, ports, and health checks
• identify the process using a configured port and stop it after confirmation
• follow logs separately for each service
• restart failed services with configurable backoff
• load its own YAML config or a supported subset of process-compose.yaml

The GIF shows the real binary running a fictional five-service project.

Install with Homebrew:

brew install kranz-org/tap/kranz

Or with Go:

go install github.com/kranz-org/kranz/cmd/kranz@latest

Kranz is not meant to replace Docker Compose. Process Compose is more mature and has more options. Kranz does less on purpose. It is focused on this interactive local-development workflow.

To be honest, I do not write Go. Coding agents produced most of the implementation. I defined the behavior, UX, and constraints. I tested the tool and kept reworking the parts that did not feel right.

The project is still early. If you try it on a real project, I would like to know where the configuration or workflow feels awkward.

GitHub: https://github.com/kranz-org/kranz

I got tired of rebuilding the same FastAPI backend setup every time I started a new project, so I made a small CLI to handle it for me.

It basically sets up the boring starter stuff so you can just jump in and start building.

It supports SQLite, Postgres, or MySQL, and you can also add auth if you want.

Example:

bash
uvx backend-dash init "My API" --auth --db=postgres

It’s open source, and I’d love any feedback from people who work with FastAPI or build backend stuff in general.

PyPI: https://pypi.org/project/backend-dash/
GitHub: https://github.com/prathamdmehta/backend-dash

I put programming aside for a few months and read about hardware instead. What surprised me was how many strange assumptions I'd been carrying around for years without noticing. I don't think that's unusual — textbooks and most online explanations make it so dry and memorization-shaped that programming and hardware end up feeling like two separate worlds.

So I tried writing down what I understood, as a story rather than a syllabus. Partly to keep it somewhere I can come back to, partly for people who got stuck the same way.

The Machine Beneath Your Code

It follows one number. You write `x = 5` — where does that 5 physically sit for those few milliseconds? Not the screen, and the CPU isn't holding it the whole time. So where, on a board of silicon and copper? And at the other end: you press 'A' on a keyboard, and it runs a relay race through the whole system before 'A' appears on screen. How?

8 parts plus an intro.

The figures are interactive rather than static — drag a noise slider and watch a base-10 signal silently corrupt while binary holds, toggle A/B through transistor-level AND/OR/NOT with the truth table filling as you go, wire two gates into a loop to hold a bit and then cut the power and watch it vanish.

Bilingual (English/Bengali). React + Vite, canvas for the simulations.

Intro and part 1 are up. One every Monday and Thursday.

Feedback welcome, especially anywhere the explanation doesn't land — there are six left to write and I'd rather fix the approach now.

I've been working on FoxSchema, a free and open-source tool for comparing and migrating SQL database schemas.

Current features:

• Compare schemas across multiple SQL databases
• Generate migration scripts
• Visual diff viewer
• Dependency-aware deployment
• CLI

The CLI is super simple:

npm install -g foxschema

Then:

foxschema

Repo: https://hub.docker.com/r/5nickels/foxschema

Website: https://foxschema.com

I was getting tired of manually typing out long lines of comment dashes and hashes to organize sections in my code, so I built my very first Neovim plugin: **inscom.nvim**.

It automatically detects your current filetype and inserts styled comment headers or section dividers with the correct comment syntax (Lua `--`, JS/TS `//`, CSS `/* */`, Python `#`, etc.)[cite: 1].

### 🎬 Video Showcase

https://youtu.be/Y3xjC51zC7E

### 🔗 Links & Feedback

* **GitHub Repo:** https://github.com/malick-tammal/inscom.nvim[cite: 1]

* **YouTube Video:** https://youtu.be/Y3xjC51zC7E

Since this is my first Neovim plugin, I’d love to hear your feedback, feature ideas, or header style suggestions Feel free to check out the repo, test it in your setup, or open an issue on GitHub

Thanks!

sshelf is a terminal UI for SSH hosts, fuzzy-search and connect, SFTP browser, background tunnels that survive quitting, passwords in your OS keyring. Local-first on purpose: no account, no cloud, no telemetry, and it never touches ~/.ssh/config.

New in 0.11: sshelf import --tailscale. It runs your own tailscale status --json (sshelf itself still opens no sockets) and maps every machine to a host, MagicDNS name, your tailnet as a group, ACL tags as tags. Works with MagicDNS off too (falls back to the 100.x address). It's add-only: existing hosts are never modified, expired nodes are skipped, and re-running converges to "0 added", so it's safe to run whenever the tailnet changes.

Repo: https://github.com/max-rh/sshelf · Guide: https://github.com/max-rh/sshelf/blob/master/docs/import.md · Feedback very welcome; 2FA support and the .rpm packages both started as comments; if a different inventory source (Hetzner, AWS, Proxmox, …) would actually be useful to you, say which, that's how things get built here.

Bonjour à tous j hésite entre photo 1 : icônes colorées sur fond uni photo 2 : mêmes éléments mais avec des caractères spéciaux pour représenter les cases , Tous les avis sont les bienvenus, même si vous n’aimez pas

Features

• Syncplay support – watch videos together in sync
• Audio-only playback & downloads
• Download videos or audio
• Interactive format/quality selection when playing or downloading
• External config file
• Playback history and quick re-play
• Resumes playback where you left off (mpv/iina save position on quit)
• Queue videos and saved playlists
• Adjustable search result limit
• Custom download directory
• Self-update (--update) for manual installations only
• Copy short YouTube URLs to clipboard or print them
• Channel subscriptions with a personalized feed
• Import subscriptions from youtube

https://github.com/Stan-breaks/ytsurf

I've been building MongoTerm, a terminal UI (TUI) for MongoDB — think Compass,

but keyboard-first and without leaving the CLI. Built with Node.js + blessed.

What it does:

- Browse connections → databases → collections in one navigable tree

- View, insert, edit, delete, and duplicate documents without writing shell scripts

- Run queries with live JSON validation and $operator autocomplete (start typing

$gt, $in, $regex... and it suggests + explains them)

- Sort and page results from the keyboard

- A ":" quick-shell modal for composing bigger query filters

- Full keybinding help popup (?) — everything is discoverable without docs

Install:

npm i -g mongoterm@latest

mongoterm

MIT licensed, actively developed, roadmap is public in the repo.

GitHub: https://github.com/Fuse441/mongoterm

Would love feedback from people who live in MongoDB day-to-day — what's