This post covers 0.43.0 through 0.45.0. The theme running through all three is not a feature. It is that several things which looked verified turned out not to be, and the interesting part is consistently how they were found rather than what the patch was.

Verify before you parse​

A channel webhook had no signature verification path at all. It now captures the raw body and authenticates the caller before decoding anything.

The ordering is the whole point. A signature is over bytes. Anything that parses and re-serializes first has verified a normalisation of the message, not the message. That distinction is easy to assert and hard to prove, so the test fixture is a body deliberately built to be destroyed by a JSON round trip:

ORIGINAL     = {"b": 1,\n  "a": 2,   "a": 3 }
ROUNDTRIPPED = {"a":3,"b":1}

Keys reorder, the duplicate key collapses, whitespace is erased. Feeding the verifier a re-serialized body reds exactly one test out of sixty-four — which is also the measure of how little a canonical-JSON fixture would have proved.

Nine guards ship with it, each verified by deleting it and watching a named test change colour. The two refusal sites are deliberately independent: removing the load-time guard reds two integration tests while all sixty-four unit tests stay green, and removing the request-time guard does the exact reverse. Neither half silently carries the other — the same doctrine the connector and bearer-token fixes established earlier.

The signature schemes themselves are not here yet. A declared-but-unperformable verification is a load error before a port is bound, so nothing degrades quietly to unverified while you wait.

One walk, so it cannot narrow again​

flux hides registered credentials from logs, from models, and from saved transcripts. An earlier release closed a hole where the walker that scans saved JSON skipped plain numbers — which matters because an all-digit credential is invisible to every heuristic flux has, making registration its only protection.

Fixing it turned up three more copies of the same traversal. Two of them fed durable stores, and those two also skipped object keys.

Four independent hand-rolled walks of one shape, each free to narrow on its own. That duplication was not a tidiness problem — it was the mechanism by which the defect could exist at all, because there was no single place where "total" was defined. There is now one walk, and its match is exhaustive with no catch-all, so a new JSON node kind fails the build rather than being silently skipped.

A related fix in the same area is worth stating plainly because the direction was wrong rather than the code: when text-level redaction corrupted a recorded request badly enough that it no longer parsed, the fallback returned the unredacted original. It failed open, and silently. It now refuses.

The editor grammar parses the language​

flux ships a tree-sitter grammar that Helix, Neovim and Zed use. It could not parse 7 of 15 of flux's own canonical examples — 166 error nodes across six constructs it never supported, including bare-identifier binds, ctx blocks and +=.

Why nobody noticed is the useful part. The grammar repository had its own three-file example corpus, and its CI parsed that one. At the identical revision that corpus was 100% clean while flux's was 47% broken. A second corpus did not merely permit the drift — it certified it.

That is now closed at both ends: the grammar parses all fifteen, its CI parses flux's corpus with no allowlist, and a check on this side verifies that the exact revision flux pins can parse the canonical examples. Moving that pin, it turns out, was the step that had been quietly missing — two earlier grammar improvements had landed and reached nobody because the pin never moved.

Editors also stopped rendering ordinary identifiers as punctuation, which in the language server was worse than a colour problem: those tokens were emitted not at all, so an editor lost the identifier entirely.

Also in this release​

• Connector deliveries — point a channel at an installed connector and flux reads that connector's own description of itself. Every rule in it is re-checked as a load error before a port is bound, so a description edited after publication cannot start a channel that quietly does nothing.
• http.request returns a record — {status, headers, body} instead of one flat string, so a flow can select a field. Note the action-needed item from 0.43.0 if you consume it as text.
• Panes actually appear. The pane.* vocabulary shipped inert in 0.42.0; the surface sink is now installed, and both remaining links of the delivery chain are pinned by tests that fail independently.
• Plugin catalog refresh without a restart, where a refresh can only ever narrow what a plugin may reach — a refreshed manifest asking for more is refused outright.
• Configured [limits] are now observed end to end on the app-journey path, proven by breaking links in the middle of the chain rather than at its ends.

Action needed​

• A webhook that listens beyond your own machine must state its verification. If it has a token and no verification, add verify "none" to keep today's behaviour. flux refuses to start otherwise, names the channel, and prints the exact line to add — rather than opening a port whose protection you might have assumed. Webhooks bound to loopback are unaffected.

A note on how these were found​

Nearly every item above came from a review or an implementor's audit rather than from a roadmap — and in several cases the story describing the bug was itself wrong. One claimed a truncation mechanism that provably does not exist. One was blocked on a dependency constraint that had lifted weeks earlier. One named the wrong root cause, the wrong fault model and the wrong colour.

Each was corrected by the person implementing it, with evidence, before the fix shipped. That is worth more than any single entry on this list.

Full engineering detail, including the review findings behind each change, is in the CHANGELOG.

The headline is that flux can now sit in a room with several people. The subtler half is that three of the nine stories in this cut are foundations whose consumers are not wired yet — and saying so plainly is more useful than a feature list that implies otherwise.

Rooms — one participant among several​

Every channel flux had was one-to-one or fire-and-forget. schedule, webhook, slack and a2a wake a journey and return. The voice path was richer but assumed exactly one caller, because on a phone line there is only one candidate.

A room breaks that assumption, and the break is not cosmetic: every inbound event now carries an occupant id. Attribution is not a feature layered on top of a room, it is the precondition for one. Without knowing who spoke, "answer only when addressed" cannot even be expressed.

Two stories landed together. The Room port (join / occupants / say / whisper / leave, plus a Joined/Left/Message/Ended event stream) arrives as an ordinary channel kind, so a room reaches an agent through the same machinery every other channel uses — and a room-sourced turn dispatches through the ordinary executor and approver, which is asserted by a test rather than assumed.

The XMPP MUC backend then makes it real against any standards-compliant server — prosody, ejabberd, or a hosted JaaS tenant — with no browser and no vendor SDK.

Why the dependency choice was a safety decision​

The obvious move was an existing XMPP client crate. We rejected it, and the reason is worth stating because it generalises: tokio-xmpp opens its own TCP socket and resolves its own DNS. That means its egress cannot be routed through flux's network guard — every outbound request in flux passes one guard that resolves hostnames and blocks private, loopback and link-local ranges unless the caller holds a scoped grant. Using that crate would have meant either a bypass or a second guard, and the invariant forbids both.

So we took quick-xml — a parser, not a client — and wrote the protocol here, about 200 lines of element tree. It is the only new package in the lockfile, and no second TLS stack came with it.

Two details from a live spike are now regression tests, asserted against the raw frames the server actually reads: every stanza is namespace-qualified (prosody answers <unsupported-stanza-type/> and kills the stream otherwise), and the keepalive is an XMPP ping, never a whitespace frame — a bare space gets the connection closed with 1007.

What is deliberately not finished​

The agent replies to every line said in the room. The addressing rule is carried in settings and not yet enforced; that is the next story. Under the in-process test double this was theoretical. With a real backend it is a live cost, and you should treat a room as something you put flux into deliberately, not something to leave running.

The history you already have​

If you use codex, claude-code or opencode, you have years of transcripts on disk. Their token-usage parsers already walk right past the message text to reach the eight integers they came for.

This release extracts that text — normalising roles across three different vocabularies — and exposes it as search(query, harness).

The containment is the story, not a caveat on it. Because this is the change that exposes the data, it is the change that has to contain it, and each property is structural rather than maintained:

• Off by default, by construction — the default tool pack literally is the history-enabled one called with history disabled, so there are not two declarations that could drift apart.
• Redacted and escaped at ingest, not at render. The test asserts on the record sitting in the index, because redaction-at-render is the failure mode that looks identical from a passing test.
• Per-harness permission, so granting search over one harness is not granting it over all.
• The escaper is the one flux already uses for untrusted knowledge-base bodies, exported as a one-line delegation so the two callers cannot drift into two schemes.

Nothing in flux wires this up yet. That is deliberate: extraction shipped one release before this one specifically so unredacted text could not reach a model-visible surface before redaction existed.

Two limits are documented rather than claimed solved: the over-fetch behind the harness filter is a heuristic, not a bound — a harness holding many better-scoring hits can still cause a silent under-return — and a host must pass one history handle to both ingest and registration, because they take independent handles today.

Resource ceilings that actually reach something​

A configured [limits] table now binds for the flux binary and descends into sub-agents. It is per-child: max_concurrent_tool_calls = N bounds each agent, so a process with k live children may run up to N×(k+1).

That is weaker than it sounds and we are saying so rather than letting the name imply otherwise. A shared ceiling was built first — and reproduced a real deadlock, where a parent holds a permit while awaiting a child that queues on the same semaphore. Per-child is safe by construction: parent and child hold different semaphores, so no ancestor can block a descendant.

Not covered: flux app run assembles its own environment and still ignores [limits] entirely.

A prune that would have eaten your memory​

memory:* streams carry no registry row, which is exactly what the ad-hoc stream prune targets. An aged memory was indistinguishable from an aged scratch stream and would have been swept.

It was caught before it could bite — the prune has no caller anywhere in the tree — so this closes a trap rather than fixing an incident. Whether memory should ever be prunable by age is now answered in writing rather than left implicit: it should not be, and forget remains the deliberate path.

Also in this release​

• Flux Glyph, a compact indented opcode projection of a Flux program, for agents. The round-trip is proven as a property across every node kind in three nesting positions, plus hundreds of seeded random programs. .flux and the runtime are untouched.
• pane.open / update / close — an agent can open its own panes. Shipped partial: the ops are surfaced only when a host has a surface sink, and nothing installs one yet, so the vocabulary is currently inert.

Action needed​

• If you implement a voice handler, its turn method now takes a speaker alongside the text. If you only use flux's built-in phone/voice support, the single caller on a line is simply named now instead of anonymous, and nothing changes for you.
• If you construct SubAgents with a struct literal, add the new field or switch to SubAgents::new.

Full engineering detail, including the review findings behind each change, is in the CHANGELOG.

Nothing here needs an API key or a network call. Every command and every output below was run against a throwaway git repository, and pasted verbatim.

Set up a scratch repository​

Do this somewhere disposable. The flows below make real commits.

mkdir /tmp/flux-tutorial && cd /tmp/flux-tutorial
git init -q
git config user.email you@example.com
git config user.name "You"
echo "# demo" > README.md
git add . && git commit -qm "initial commit"

One file, several workflows​

Before named entrypoints, a file held one workflow and a family meant a file each. Now a module can declare several top-level flows and the caller picks one by name.

Save this as repo-notes.flux:

flow status -> Any
  state = git_status()
  recent = git_log(limit: 5)
  return { state, recent }

flow start(branch: String) -> Any
  switched = git_checkout(branch: branch, create: true)
  return { switched }

flow save(message: String) -> Any
  git_stage(paths: ["."])
  committed = git_commit(message: message)
  return { committed }

flow land(onto: String, branch: String) -> Any
  git_checkout(branch: onto)
  merged = git_merge(branch: branch, no_ff: true)
  return { merged }

flow undo(commit: String) -> Any
  reverted = git_revert(commit: commit, mainline: 1)
  return { reverted }

Five workflows, one file. Two things in that source are worth naming, because both are newer than most examples you will find:

• No $ sigils. state = git_status() binds a result directly. The older $state = … spelling still parses, but this is the canonical form the formatter now emits.
• Named inputs look named. git_merge(branch: branch, no_ff: true) instead of wrapping arguments in an object literal. { state, recent } is shorthand for { state: state, recent: recent } — punning is allowed only where the names are identical, so it cannot quietly change meaning.

Run the read-only one first:

flux run repo-notes.flux --entry status --yes

flow  low · mutating · 2 op(s)

→ git_status
  ✓ ?? repo-notes.flux  · exec 6ms + approval 1µs

→ git_log   limit=5
  ✓ fa51d90 initial commit  · exec 6ms + approval 1µs
{"recent":"fa51d90 initial commit","state":"?? repo-notes.flux"}
──────────────────────────────────────────────────────────────── 2 steps · 33ms

Every operation is listed with its arguments before its result. That trace is not a log the flow chose to print — it is the execution path itself, and the ops in it are exactly the ops the source names. No model decided to call git_log; the flow did.

--entry reuses the strict authored-flow input path, so a flow's declared parameters are checked. Ask for a flow that does not exist, or omit a required input, and it fails before doing any work rather than midway through.

Landing a branch​

Commit the module, then start a branch through the flow:

git add repo-notes.flux && git commit -qm "add the workflow module"
flux run repo-notes.flux --entry start --arg branch=feature/notes --yes

→ git_checkout branch="feature/notes", create=true
  ✓ Switched to a new branch 'feature/notes'  · exec 6ms + approval 1µs

Make a change and save it. save takes its message as an input, so the commit text is a caller decision while the sequence — stage, then commit — is fixed by the flow:

echo "hello" > note.txt
flux run repo-notes.flux --entry save --arg message="add a note" --yes

→ git_commit message="add a note"
  ✓ [feature/notes 40c5b1f] add a note
     1 file changed, 1 insertion(+)
     create mode 100644 note.txt  · exec 7ms + approval 1µs

Now land it. no_ff: true forces a real merge commit even where a fast-forward was possible, so the branch stays visible in the history:

flux run repo-notes.flux --entry land --arg onto=main --arg branch=feature/notes --yes

→ git_merge branch="feature/notes", no_ff=true
  ✓ Merge made by the 'ort' strategy.
     note.txt | 1 +
     1 file changed, 1 insertion(+)

*   082036e Merge branch 'feature/notes'
|\
| * 40c5b1f add a note
|/
* 71fda9e add the workflow module
* fa51d90 initial commit

A merge is Risk::High and a conflict is a recoverable error: it names the conflicting files, aborts, and restores the tree. It is never left half-merged for something else to trip over. If a merge is already in progress git_merge refuses outright and aborts nothing — that in-flight resolution may be work someone has not saved.

Undoing without rewriting​

This is the part worth internalising. git_revert appends the inverse of a commit. It never resets, and it never rewrites history.

For a merge commit you must say which parent to keep, which is what mainline: 1 means — the branch you merged into:

flux run repo-notes.flux --entry undo --arg commit=082036e --yes

→ git_revert commit="082036e...", mainline=1
  ✓ [main b6f5817] Revert "Merge branch 'feature/notes'"
     1 file changed, 1 deletion(-)
     delete mode 100644 note.txt
    reverted 082036e — b6f5817 Revert "Merge branch 'feature/notes'"

* b6f5817 Revert "Merge branch 'feature/notes'"
*   082036e Merge branch 'feature/notes'
|\
| * 40c5b1f add a note
|/
* 71fda9e add the workflow module
* fa51d90 initial commit

note.txt is gone from the working tree, and both the merge and the original commit are still reachable. The record of what happened survives the decision to undo it — which is what you want when an agent, rather than a person, made the call.

Where to go next​

Three more things landed in the same window that extend this shape:

• Work boards can be read as structured data, not just text — a flow can loop over items, filter to what is ready and not blocked by unfinished dependencies in one call, and read back its own notes. Since 0.38.0 a board can also hand an item to a different worker when its holder dies, and attach evidence such as a commit or PR link to a finished item. See datasources.
• Delegated helpers are visible while they work. When flux hands work to helper agents, a status line shows each one's role, how long since it last did anything, and whether it is working or stuck. Their inputs and outputs are never shown — only that activity happened — so a helper handling secrets cannot leak them onto your screen. Local helpers today; remote workers stay silent for now.
• A flux program can drive its own release, having a model draft the changelog prose while the version number is derived from commit titles rather than from anything the model says. See improvement.

If you want the deterministic-execution model behind all of this, start with Flux-Lang overview; for the operation catalogue, see operations.