i had the same problem and built something similar but with a different approach. greens (https://github.com/yuvrajangadsingh/greens) is a CLI that runs locally on your machine. it mirrors commit activity from your private/work repos to a personal repo via a cron job. no tokens shared with any third party, no web app, no account.
the tradeoff vs your approach is it only works going forward (can't backfill years of history), but nothing ever leaves your machine.
to answer your honest question #1: yes, this is a real problem. i posted about it on linkedin and the response was way bigger than i expected. lots of devs working at companies where all their output is invisible on their public profile.
fair point on regex being brittle for edge cases. it works well for the obvious patterns (empty catches, bare excepts, hardcoded secrets) but yeah it wont catch everything.
for vibe coding sessions thats actually the main use case i had in mind. run it after a generation pass to catch the low-hanging stuff before it gets committed. zero config so you can just pipe it in.
yeah that makes sense. regex catches the surface-level stuff fast, but logic bugs and spec drift need something smarter. the AI layer on top of deterministic checks is a good approach.
vibecheck is intentionally the dumb fast pass, sounds like caliper handles the deeper analysis. will check it out.
I kept writing the same boilerplate to call embedding APIs from scripts. Wanted something like httpie but for embeddings.
vemb wraps Gemini Embedding 2, which is the first model that natively embeds text, images, audio, video, and PDFs into the same vector space. Free API key from Google AI Studio.
One command: `vemb text "query"` gives you a vector. `vemb search ./docs "find similar"` searches a directory with caching. `vemb similar a.jpg b.jpg` gives you cosine similarity.
The multimodal part is the differentiator: you can search a folder of images using a text query, or compare a PDF to an audio file. Same embedding space, no transcription step.
Would love feedback on what output formats or integrations would be most useful.
Fair point about web fetch already being a trust boundary. The difference I see is that web fetch returns data, but WebMCP tools can define actions. A tool called "add_to_cart" is a lot more dangerous than fetching a product page. The agent trusts the tool's name and description to decide whether to call it, and that metadata comes from the site.
But yeah, if you're already letting agents browse freely, the incremental risk might be smaller than I'm imagining.
Nice, similar energy to lazygit but as a single binary. The AI commit message generation is useful but I'd want a way to set a template or convention (conventional commits, etc.) so it doesn't just freestyle every time.
One thing: piping the install through curl | sh makes some people nervous. Might be worth adding a homebrew tap or at least a checksum for the binary.
I've been using MCP with Claude Code for a while now (Google Maps, Swiggy, Figma servers) and the local tool-use model works well because I control both sides. I pick which servers to trust, I see every tool call, and I can deny anything sketchy.
WebMCP flips that. The website exposes the tools and the browser decides what to call. The security model gets a lot harder when you're trusting random sites to define their own tool interfaces honestly. A malicious site could expose tools that look helpful but exfiltrate context from the agent's session.
Curious how they plan to sandbox this. The local MCP model works because trust is explicit. Not sure how that translates to the open web.
The session itself is mostly noise. Half of it is the model going down wrong paths, backtracking, and trying again. Storing that alongside the commit is like saving your browser history next to your finished code.
What actually helps is a good commit message explaining the intent. If an AI wrote the code, the interesting part isn't the transcript, it's why you asked for it and what constraints you gave it. A one-paragraph description of the goal and approach is worth more than a 200-message session log.
I think the real question isn't about storing sessions, it's about whether we're writing worse commit messages because we assume the AI context is "somewhere."
the tradeoff vs your approach is it only works going forward (can't backfill years of history), but nothing ever leaves your machine.
to answer your honest question #1: yes, this is a real problem. i posted about it on linkedin and the response was way bigger than i expected. lots of devs working at companies where all their output is invisible on their public profile.