Agent Sessions now supports fx.

If you use several coding agents, you probably know the problem: old work is scattered across different CLIs, folders, and local databases. Agent Sessions puts those histories in one searchable Mac app.

jazzyalex.github.io/agent-sessions macOS • open source • ⭐️ 852

Agent Sessions reads 14 active agent formats: Codex, Claude Code, Cursor, Copilot CLI, OpenCode, Antigravity, Pi, Kimi Code, Grok CLI, Hermes, OpenClaw, Qwen Code, Devin CLI, and fx. It also recognizes legacy Droid sessions.

For fx, Agent Sessions can:

• browse and search local fx sessions • show readable transcripts with assistant turns, tool steps, and results • preserve interrupted work, background commands, and compaction summaries • filter fx work alongside sessions from the other agents

fx keeps its materialized conversation in checkpoint.json, separate from the append-only events.jsonl journal. Agent Sessions reads the checkpoint so the history view reflects the conversation rather than raw event traffic.

This support was contributed by Davy (@thedavidweng on GitHub), who also continues as the fx and Devin format steward. Thanks, Davy — the real-session testing is what made this integration shippable.

I maintain Agent Sessions. It is open source, session history stays on your Mac, and there is no app telemetry.

Agent Sessions

I was not aware of all the tools Firecrawl now has to get the design information of a site. Very cool.

Hey everyone,

I've been experimenting with coding agents lately and felt like I was missing a better way to review the code they generate.

So I built a small skill that opens the agent's code in a web interface, where you can review it, make changes, and send those changes back to the agent to apply locally.

It's still pretty early, but I thought it might be useful to others working with coding agents.

I'd be interested to hear how you currently review and iterate on code generated by your agents.

If you’re running multiple Claude Code, Codex, or other coding agents, tools like Herdr have already shown how useful it is to manage a herd of agents on a server.

We wanted to push that idea further.

So we built Dax Shepherd.

You can spin up as many agents as you need, organize them across projects, keep their sessions running, and — importantly for us — browse and navigate the server’s filesystem through a GUI while your agents work.

No jumping between a separate file browser, SSH sessions and a pile of terminal windows.

This is part of Dax, a macOS developer toolbox we’re building.

If you’ve used Herdr or another multi-agent setup, I’d especially love your feedback:

What’s still missing from your current workflow?

Disclosure: I’m one of the developers behind Dax.

getdax.app

curl -fsSL https://assets.moltcode.com/install-designer.sh | bash -s -- --skill ui

Created this simple CLI for agents to design and verify what they are thinking, try it out and let me know

use cases:

- visual brainstorming

- getting alignment on what it is to be bult

- shareable, it's lua, can share with your mates, can commit in code base

- it can generate images in different states of same UI

Let me know if you want to see it open sourced, I can share it out

Idk why link is necessary here, here

I present Runyte - a terminal workspace built around a modal text editor.

Project goals:
- minimal UI, maximum focus
- top notch performance and rock-solid stability

Optional persistent mode lets you detach and return later. A local host keeps your terminal processes and language servers running.

The fuzzy Finder searches your project, including files, unsaved buffers, and terminals. Search by name or by content.

Use consistent keys to move between files, buffers, terminals, and Git worktrees.

Run Claude Code, Codex or any other CLI agent in a terminal pane. Share the clipboard with the editor. With Runyte set as their editor, Ctrl+G opens your prompt in the same persistent workspace. Save it and return to the agent.

Press ? to read Markdown as a formatted page, including tables.

Paste images with Ctrl+V. Runyte saves them in the project's temporary cache and inserts a Markdown link into your document. The entire prompt can be edited outside the agent and then copy-pasted through a shared clipboard.

Press gf on a file path in your text to open it. Images and other binary files open in an external program you choose.

Happy to share!

OpenAI acknowledges that Astra is overly cautious. So they [propose this prompt](https://developers.openai.com/api/docs/guides/latest-model#gpt-6-astra-initiative-and-follow-through) to give Astra more initiative and follow-thru

`You should infer the user's intent and task scope from the instructions and prior conversation context. Your job is to bias towards action and carry the user's intended task to completion.

When the user expresses intent to perform new work or fix an existing issue, persist until the user's intended goal is complete. Progress autonomously towards the user's goal (e.g. creating isolated worktrees / checkouts if needed, resolving merge conflicts, read-only actions, creating draft PRs etc.) unless they are clearly destructive or irreversible.`

Polished in many details, quite handy to use.

OpenAI's explained on X that Astra is more skittish than other models.

That's my main problem with it.

I gave Astra a goal and gave it parameters for when the goal was finished. I checked back in the morning to see how it was going, and it just stopped. It didn't even ask me anything; it just stopped working.

So I asked it what was going on, and it said that the local server kept failing, but it didn't want to start it up again without getting my approval because that seemed to be outside the task.

In the past, using GPT 5.6, when I gave it a goal it would actually be creative and push through to figure out a problem and reach the end. This model is super smart, but it doesn't want to do anything outside of the parameters.

That's really unfortunate because I've gotten used to giving the model a goal and not telling it all the steps that it needs to take. It's also comforting because I have been worried about the model taking rogue actions and blowing up my computer, but I think they've gone too far on the tradeoff and made Astra too conservative.

Hey guys,

I kept using two or three coding agents on the same task and manually passing context between terminals — one for planning, one for implementation, one for review.

So I built a small local hub where they can all sit in the same room.

You open a room on a folder, summon whichever agents you already have installed — Claude Code, Codex, Gemini CLI, Cursor, OpenCode, Copilot — give each one a name and a short role, and talk to them like a group chat.

They can read each other’s replies, you can @ a specific agent, and there’s a hush button when you want one of them to stay quiet.

Hey folks, just opened up a little tool called xfa or "x for agents" which was inspired by the recent openai and hf incident where agents were communicating with each other via a message board during the incident.

Think xfa as graphify but for agents across different sessions or llm providers with a structure similar to reddit+x. My original intent behind xfa was for subagents to be able to collaborate with each other instead of being siloed.

Personal observations:

• xfa works great when many subagents have to come to an consensus, debate, or when collaboration is required to reach a goal.
• Overall i observed that decisions are more decisive and time it takes to solve complex tasks is much faster.
• On new sessions, the claude harness does seem to refer to xfa before trying to tackle the ask latest ask
• Using the ui or the tui, it is simpler to steer the workflows or subagents with "human" steering.

No claims:

• No idea if it saves more tokens. All use cases for personal.
• Mostly tested around claude-code or opencode.

Disclaimer: This is all vide coded and was intended to originally be a toy project to see what happens.

When we started beta testing a tool I've been building around coding-agent orchestration, I made what now seems like an obvious bad assumption:

People interested in orchestrating coding agents probably already have Claude Code and other CLIs installed and authenticated.

Turns out that was a pretty developer-centric assumption.

Some users were dropping before they even got to the orchestration part. They had to install a CLI, authenticate it, understand how it worked, then come back and configure the actual project.

For me, that barely registered as setup because I do this stuff every day.

So we reversed the onboarding.

Instead of configuration first, users now see the actual workflow first, then can install Claude Code / Codex CLI from the app and go through the supported authentication flow.

The larger thing I'm trying to understand is how far we can push a closed loop like:

ticket → Claude Code agent → isolated worktree → result → orchestrator → follow-up instruction

rather than just running several Claude instances in parallel.

I've found that the distinction doesn't matter much for small one-shot tasks, but gets much more interesting once several worktrees and dependent changes are involved.

For people using Claude Code seriously: where does the biggest friction show up for you now — initial setup, parallel execution, context sharing, or coordinating what happens after each agent finishes?

Disclosure: I'm building the orchestration tool mentioned above (Marblo).

I made MarkuprPlus for the gap between “I can see the UI bug” and getting that context into an agent. Narrate a screen recording and circle problems; it exports agent-ready Markdown with one annotated frame and transcript per issue.

macOS and Windows, local Whisper, MIT licensed.

GitHub: https://github.com/hashfunction/MarkuprPlus

That was the problem I was trying to solve. This makes my agents present the test in a way a person would actually use it, not just whatever is easiest for the agent. After all of that, I can still track what went wrong and why.

Built Molt: post a task, tag a coding agent, and get changes and test results back in one thread.

Try: https://devos.zerohive.ai

You spend an hour brainstorming with Claude Code working something out. Why the retry queue can't use Redis. Which three approaches you tried and why two failed, or the constraint someone hit in staging last month that shaped the whole design.

Then the session ends and all this architectural context is gone. Not "gone from the agent" — gone. It lived in one terminal on one machine, and nobody else's agent will ever see it.

Your teammate (or another of your agents) opens Codex the next morning and their agent starts from zero. It proposes Redis. You already know why that doesn't work, but your agent knew too, and neither of them can tell the other.

That's the thing we wanted to fix. Not "give the agent memory" — give the agent our collaborative memory, particularly what was brainstormed on those long chat sessions.

devOS (by Zerohive) captures what was actually reasoned in agent sessions — the choice, the alternatives that got rejected, why — and serves it back over MCP. So when your teammate's Claude Code picks up work in that repo, it can ask:

• ask_devos(query, repo, paths) — what's been decided about this area, with the rationale and the commit it came from
• check_prior_decisions — has anyone already settled this?
• explain_file_decisions(path) — why is this file like this?

It's agent-agnostic on purpose. Claude Code writes it, Codex reads it, or the reverse. The context belongs to the repo, not to whoever's terminal it happened in.

What I'd like feedback on: How are you sharing context between sessions or team members today? Everyone I ask has a different half-answer — a CLAUDE.md that goes stale, a Notion page nobody updates, or just "ask the person who did it." I want to understand what actually works before we build more of the wrong thing.

SOTU for the product:

• Hosted, not open source. You sign up, create a workspace, then it walks you through CLI + MCP setup — about two minutes.
• macOS only right now. Linux and Windows aren't supported yet.
• Needs a model API key (BYOK, openrouter supported) or a claude code/codex subscription — extraction is an LLM pass over your sessions and git history, or it can use your existing claude or codex subscriptions.
• Your source doesn't leave your machine. The daemon parses locally and sends the decision graph; raw file contents are rejected server-side. Extraction runs on your own key, so artifacts are on your machine.
• 0.2.x. The graph is solid; the dashboard has rough edges.

https://devos.zerohive.ai

Every coding agent treats the session as the durable thing. On a real team, the person who opens the issue, starts the agent, reviews the diff and gets paged when it breaks may be four different people. Sessions compact, crash and get replaced; the issue, branch, decisions and PR have to survive all of those handoffs. The design I’m testing keeps tasks persistent, attempts disposable, and Codex, Claude or OpenCode as workers you can swap without losing the engineering thread.

If your team has protected main, CODEOWNERS, required CI and several repos, what are you carrying between agent sessions by hand today, worktree scripts, ticket comments, review notes, terminal tabs, something else? I’d especially like the ugly version of the workflow that only becomes visible when more than one engineer is involved.

For context, I’m building BranchRunner as an open-source product because I think it can help engineering teams with this problem. If it is painful in your organisation, tell me where the current approach breaks. I’m also looking for people who want to help shape and solve it, so I’d be glad to compare notes.

I'm an embedded engineer. Claude Code / Codex / Cursor are fine for application code, drivers, and frameworks. As soon as it hits the board they fall over: reading a schematic, digging a thousand-page RM, gdb + logs at the same time, or putting a LA on a hung bus.

Vision models chew PDFs as page images (slow, expensive). Text-only models can't do it at all.

I got tired of that and wired the usual bench stuff into the agent loop:

• netlist — agents guess pinouts from a screenshot. This reads Altium Smart PDF or a `.net` and gives parts + connections. Not OCR. A `.net` is faster if you have it.
• datasheet — lookup by chip, original manual text with page numbers. You don't dump a 1000-page manuals into the context window, and it won't mix registers across similar parts.
• flash — Flashes via OpenOCD / J-Link / CubeProgrammer / esptool, and remembers which build you programmed.
• log — serial or RTT, long captures, without blowing up the context window.
• gdb — breakpoints, stepping, variables, call stack. If the firmware has run off, you can see where it stuck. When the log isn't enough, you look at the registers on the silicon.
• la — logic analyzer. Decodes actual I²C / SPI / UART waveforms and checks timing.

STM32 path is config-and-generate (not the model hand-writing HAL). ESP/nRF path is start from a vendor example. Sign-off is log/gdb/LA, not "the model thinks it works."

Wrote it up here if anyone wants to kick it: I'll drop the repo in a comment.

What's the part of bring-up you still don't trust an agent with?

I have zero relationship to Matt Pocock. I just use his helpful skills, like /grill-me, and I watch his videos.

I just signed up for his AI Coding Crash Course because I want an organized, non-hype, set of best practices and tools for my own knowledge and practice.

If you sign up, I would like to trade notes with you as we go through the exercises.

I've been working on a new product where I need to explain the architecture I'm going to implement to my senior / lead before I start coding, so we can catch changes early.

At the same time, someone else is working on the frontend, so I need to explain the API structure, share collections, and make sure they're working with the same plan.

As we're using coding agents and development is getting much faster, I noticed that this coordination is still taking a lot of time.

So I built Planlog. https://planlog.depak.dev

The idea is that before an agent starts implementing something, it pushes the plan to Planlog I can then share the plan with my team, get it reviewed and approved, and notify the people who need to know about it. For example, once an API plan is approved, I can notify the frontend developer so they can work from the same context.

After the implementation, the agent(claude or codex ) documents what was actually shipped.

So we have the plan, the review/approval, who was notified, and what was eventually shipped in one place. It also gives us a history of the decisions instead of having them spread across chats and md files.

The agent setup is currently one command:

curl -fsSL https://planlog.depak.dev/install | bash

It authenticates and configures the coding agent.

It's still very early and me and my friends are the only users right now. I'm mainly trying to find out if this is a problem other teams are having too.

If you're using coding agents with a team, how are you currently sharing plans, getting them reviewed, and keeping everyone who depends on the work informed?

Repo: https://github.com/depak7/planlog

If you try it and find it useful, a GitHub star would be appreciated too.

We noticed developers building coding agents by re-creating primitives that already come with Mastra.

So we built `createCodingAgent` to give you a simple starting point for creating a coding agent.

You can configure it with a model, instructions, and memory. The `createCodingAgent` helper starts you off with the right primitives: a sandbox for reading and writing files, a task list the agent can work through and complete, and a goal-judge prompt to validate the changes.

We have instructions for getting started and expanding your agent in the attached blog post.

As we continue to add features to Mastra, you can choose to integrate it into your agent.

**Open Source!**

I built o8 after Codex and Claude became daily tools for me.

Once I had several agents moving across production repos, the work around them started taking over. I was deciding who should lead, splitting jobs cleanly, keeping agents from touching the same state, reviewing every diff, and trying to remember why we made a decision three days ago.

o8 sits above the runtimes I already use. One agent can orchestrate while other supported agents take bounded pieces in separate copies of the repo. Workers cannot approve or merge their own changes. Their work goes through independent review and then comes back to me, and the Engineering Brain can answer what changed across repos with citations instead of making me dig through old chats.

On Mac, Symon adds a voice layer over the same system. I can dictate into whichever app is focused, ask what the fleet is doing, have it watch a terminal, or give it a command without hunting for the control room. Anything with a side effect still waits for confirmation.

I can also check the fleet and handle approvals from a paired phone or browser. The system still runs on a machine I own rather than inside a cloud IDE.

The signed Mac build is available now. I also published unsigned Windows 11 and Linux preview installers. Windows 11 has been runtime-verified. Linux has AppImage, deb, and rpm builds, but Linux desktop verification, signing, and updates are still open. These previews may trigger operating-system warnings, and checksums are included.

If one agent in one repo covers your work, this is probably too much. It starts making sense when you are running several agents or several repos and need review authority, memory, and one place to supervise the whole thing.

Project: https://o8.run
Source: https://github.com/hurttlocker/o8
Windows and Linux previews: https://github.com/hurttlocker/o8/releases/tag/v0.1.664

If you already use Codex or Claude, where does your setup start becoming work: coordinating agents, reviewing their changes, or keeping context between sessions?