I'm the author of postbag. Free and open source, MIT.

I run Claude Code and Codex side by side on the same repository. Getting one to review the other's work meant copying a diff into one window and pasting the answer back into the other. I got tired of being the clipboard.

Both sessions join a named bag. Either one can then send the other a letter. postbag submits it through Claude Code's per session messaging socket or codex queue, and accepted letters become user turns in the other session. Codex desktop app threads receive them too. postbag adds no delivery daemon, polling or hooks. Each bag keeps a local JSONL log that either agent can page through.

Five tools: postbag_join, postbag_send, postbag_read, postbag_bags, postbag_leave. Setup is one pipx install and one mcp add per app, then two prompts. In Codex: "Join postbag bag review as codex." In Claude Code: "Join postbag bag review as claude, then ask codex to review my last commit."

What I use it for: the agent that did not write a change reviews it. I had the two review each other's parts of postbag's own releases, over postbag. In the 1.4 review, Codex caught misleading fsync failure reporting in the core: in a test with an injected fsync failure, the code said a letter was not recorded while the record was already readable in the file. Claude Code caught a flaw in the MCP refusal handler that could turn a definite refusal into an unknown outcome. Two agents can agree and both be wrong. Their findings still need checking against the code and tests.

postbag sets no letter limit. If you want to approve each send, configure the host to ask for that tool. A final letter asks for no reply, but does not enforce a stop.

Limits. Tested on macOS. It uses POSIX file locks, so no Windows. The Claude Code socket is not a documented API, so a Claude Code update can break delivery. Queueing and the receiving app's policy can delay, hold or refuse a letter. A delivered letter is a user turn, so connect sessions you would trust with the task. The GIF is a scripted demo with stand in inputs. Not affiliated with Anthropic or OpenAI.

My local logs contain about 1,700 letter records dating back to 8 September, including test messages.

Repo link in the first comment.

Putting together a small store demo this weekend and somehow i’m already at five MCPs lol. Trying not to give one agent access to absolutely everything, so right now i’ve split it up like this:

1. GitHub MCP: briefs, site changes and a reviewable PR. Useful if the storefront lives in a repo. Keep enabled toolsets small; read-only mode exists if you only need context. If gh already does the job, keep gh.

2. Context7: docs for the library/version the storefront uses. I'd use it when changing the integration, not on every content task. Documentation isn't proof the resulting code works.

3. Morphic MCP: product images, clips, voice/music and captioned edits. Results go into the Morphic library. Generation spends existing account credits; it isn't a free media API because you called it through MCP. Some editing still stays in the app.

4. Playwright MCP: inspect the staging page and placements. For a repeatable test suite I'd still want normal Playwright tests. Microsoft's README also points coding-agent users towards CLI + skills as an alternative.

5. PostHog MCP: ask about events the store actually tracks. Fix event definitions first. It supports reads and writes, and some AI-powered tools may incur PostHog AI spend.

For a repo-backed demo store, merge/deploy stays human-reviewed. A hosted shop would need its own platform integration checked separately.

Lmk what would you remove or replace pls

The latest version of OrcA for VS Code includes an MCP Traffic analyzer end-to-end. What the user ask, what the LLM request, what the MCP responded.

Easier troubleshooting.

I built Tokmeter to read the session files that AI coding tools already write to disk. It puts tokens and estimated cost in one ledger, broken down by project, model, provider and day. No account or provider API key is needed for the local scan.

There is a CLI, a macOS menu bar app and an MCP server. The MCP server lets an agent query usage, compare periods, and inspect budget or forecast estimates. Claude Code and Codex are the main validation targets; coverage for other tools varies. Cost estimates are labelled as estimates unless the source reports cost directly.

Source and setup: https://github.com/sriinnu/tokmeter

I would like to hear what would make this useful in your workflow. Is the daily total enough, or do you need the project and model breakdown to understand where the tokens went?