1. October 22, 2026
   1. 🔗 oxigraph/oxigraph v0.5.13 release

      • SPARQL: improve join cost estimates and OPTIONAL planning to avoid quadratic scaling for joins on foreign keys.
      • SPARQL: preserve input bindings during type inference for subqueries, fixing joins that lost their keys after a LATERAL subquery.
      • SPARQL: allow for-loop left joins for nested OPTIONAL patterns while preserving input-dependent BIND expressions and conflicting bindings.
      • RocksDB: fix copying read options with recent RocksDB versions.
   2. 🔗 oxigraph/oxigraph v0.5.12 release

      • Remove Python 3.8 and 3.13 free-threaded build variant support
      • SPARQL: fix arithmetic grouping around signed numeric literals and group operators of equal precedence from left to right.
      • SPARQL Update: apply all deletions before insertions and make LOAD SILENT atomic, including creation of empty destination graphs.
      • SPARQL: fix filter scope in nested OPTIONAL groups and propagation through subquery projections.
      • SPARQL: fix implicit aggregation over empty inputs, IF type inference, and simplification of LATERAL joins around OPTIONAL.
      • SPARQL: allow nonpositive SUBSTR starting positions.
      • SPARQL: avoid panics when explaining expressions that cannot be serialized as SPARQL.
      • SPARQL: fix equality on rdf:dirLangString literals.
      • Datatypes: fix rounding, decimal multiplication and formatting, month subtraction, and negative fractional timestamps.
      • RDF terms: fix parsing of numeric literals within triple terms.
   3. 🔗 omerbenamram/pyevtx-rs 0.14.0: Merge pull request #48 from omerbenamram/claude/project-thread-v71itu release

      Update to PyO3 0.30 and evtx 0.13.0

   4. 🔗 omerbenamram/evtx v0.13.0 release

      No content.

   5. 🔗 exe.dev Give Your Agents Less Internet rss

      

      Without the Internet, agents are useless. With the Internet, they're dangerous.

      One approach is to allow Internet access, but through carefully controlled sippy straws. Let through only requests to destinations that you trust and deny all of the rest.

      exe now makes this easy.

      TL;DR: Run ssh exe.dev egress YOUR-VM integrations, or click the Network Access button on a VM's detail page. This will limit YOUR-VM's outbound internet access to any specific integrations you have attached to that VM.

      Exe integrations provide VMs access to other services, injecting credentials at the network edge so that secrets stay off the VM.

      

      Controlled Ingress, Controlled Egress

      Exe manages both ingress and egress. Incoming connections are private by default; you choose who can access your VM.

      Outgoing connections are open by default, with integrations providing credentials for connected services. Now you can restrict outbound traffic to just those integrations, giving agents access to the services they need while blocking the rest of the internet.

      How It Works

      Egress filtering happens at a network packet level. Anything higher level than that is subject to an end run by agents: they have memorized DNS and they can find proxies to convert traffic from one shape to another. We run our own DNS servers to prevent DNS request smuggling. And when you switch egress to integrations-only, we disable server-side web tools on requests sent through our LLM gateway.

      People used to say things like "I'm sure it's not secure against a nation- state attacker." Frontier models are the new nation-states. But unlike nation- states, we can pen test ourselves using actual frontier models.

      The agents found a bunch of escapes, all through clever use of server-side tools from Anthropic and OpenAI. There were a surprising number of them. Models are clever and persistent. And—when multiple are running on a single VM concurrently—happy to claim credit for the discoveries of others. (Here’s to you, Grok.)

      As a result, we closed that entire pathway for requests using our LLM gateway. The rest of our system survived the trial by fire. We believe that we have closed all escape routes straightforwardly discoverable by current models. We will continue to probe in-house as new models are released and harden as needed.

      Threat Model

      Turning off general-purpose Internet access does make your VM more secure, but this is intended to protect against accidents, not an APT.

      Also, it remains incumbent on you to think carefully about what an agent could do via the integrations you have attached. Are they usable as proxies for other purposes? Every read request from your agent is a write to someone else’s logs; are those writes acceptable? Put another way, your trust envelope now includes those external services.

      The traditional startup advice is to offer painkillers, not vitamins. Consider this to be Xanax; running agents should not fill you with anxiety that one mistake on their part will have disastrous consequences.

      Advanced Mode

      Our integrations give you high level access controls: connect to this Postgres server, connect to GitHub, connect to this website. If you want more control, consider setting up a proxy VM for yourself. Then set up a peer integration that allows your controlled VM to talk to your proxy VM. The proxy VM can then run arbitrary software to inspect requests and filter, augment, or forward them.

      There are no problems that cannot be solved with another layer of indirection except needing an infinite number of layers of indirection.

      Sample Transcript

      Create a new VM:

      $ ssh exe.dev new --name=no-net
      Creating no-net using image boldsoftware/exeuntu...
      
      Coding agent
      https://no-net.shelley.exe.xyz
      
      App (HTTPS proxy → :8000)
      https://no-net.exe.xyz
      
      SSH
      ssh no-net.exe.xyz
      

      It has full internet access:

      $ ssh no-net.exe.xyz curl -fsS https://exe.dev
      Agent docs: https://exe.dev/llms.txt
      Human docs: https://exe.dev/docs
      

      Limit its internet access to integrations only:

      $ ssh exe.dev egress no-net integrations
      Set egress policy for "no-net" to integrations
      

      Now the same request is rejected:

      $ ssh no-net.exe.xyz curl -fsS https://exe.dev
      curl: (6) Could not resolve host: exe.dev
      

      Create an integration that provides access:

      $ ssh exe.dev integrations add http-proxy --name inception --target https://exe.dev --no-auth
      Added integration inception
      
      To use this integration, attach it to a VM first:
        integrations attach inception vm:<vm-name>
      
      Usage from a VM:
        curl https://inception.int.exe.xyz/
      

      Attach it to our VM:

      $ ssh exe.dev integrations attach inception vm:no-net
      Attached inception to vm:no-net
      

      Access works via the integration:

      $ ssh no-net.exe.xyz curl -fsS https://inception.int.exe.xyz/
      Agent docs: https://exe.dev/llms.txt
      Human docs: https://exe.dev/docs
      

   6. 🔗 Hex-Rays Blog Hex-Rays Completes Acquisition of HexAI to Expand Its Agentic Platform Offering for Cybersecurity Research rss

      

      HexAI's team joins Hex-Rays, the company behind IDA Pro, to bring IDA technology into its agentic security research platform.

      

   7. 🔗 The Pragmatic Engineer The Pulse: Anthropic builds its own source control system rss

      Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics from last week 's issue of The Pulse . Full subscribers received the article below seven days ago. If you 've been forwarded this email, you can subscribe here .

      Interesting information from Anthropic about why the company moved off Git and built its own custom source control system. From their engineering blog (emphasis mine):

      "At Anthropic, coding is no longer the bottleneck to building systems or doing research. Claude is able to autonomously iterate on research loops, micro-optimize complex programs, and build new services from the ground up at a speed and scale we haven't seen before. The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI.

      In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day. We don't expect this rate of growth to slow down anytime soon; the latent demand for merging code is practically infinite, and every bottleneck we remove immediately leads to a further increase in the amount of code we produce."

      Anthropic saw PRs merged per day snowball 10x in less than 4 months ' time. Source: Anthropic

      That's a 12x increase in PRs in a four-month period! Interestingly, just a year ago, I shared how I had gathered Google was preparing for a similar tenfold increase across its broader infrastructure. From the deepdive published in July 2025:

      "Google is preparing for 10x more code to be shipped. A former Google Site Reliability Engineer (SRE) told me: 'What I'm hearing from SRE friends is that they are preparing for 10x the lines of code making their way into production.'

      If any company has data on the likely impact of AI tools, it's Google. 10x as much code generated will likely also mean 10x more code reviews, deployments, feature flags and source control footprint."

      Back to Anthropic, a few things about the company are different from many other tech businesses:

      • Use of a monorepo. Like most large tech companies, Anthropic has a massive monorepo, where the working copy itself is 25GB in size.
      • 25 million git checkouts per day, just for CI! All ~3,000 staff extensively use parallel Claude agents - typically 10-15 per engineer - so a lot of pull requests are created; somewhere in the region of 30,000 per day. All these PRs trigger a massive number of checkouts, mostly from the CI system.
      • Nearly all clients are always online. Git was built on the assumption that clients go offline at various times, and that when they come back up, they need to catch up with branches and merge their changes into the repo. However, when clients are always connected to the corporate internet - like at Anthropic - this assumption no longer holds. Design decisions to accommodate offline clients mean inefficient checkouts and more data transferred than necessary.
      • Hard to horizontally scale git. Scaling git is done by running git mirrors: replicating git repositories across several mirror nodes. A primary git server accepts the writes, pushes out to all mirrors, and clients fetch from various mirrors. Anthropic ran hundreds of git mirrors, but found that once their repo outgrew the mirrors' disk capacity, they could no longer scale the repo.

      So, Anthropic created a new source control system, which is called**** 'Scion' internally. It's closed source, and Anthropic has shared the high- level design principles and data structures used, but no code details. The problem with having your own source control system (and moving off Git and GitHub) is that GitHub's code review system is lost! So, Anthropic also had to build a new code review and code management system, which they call 'Antique.'

      I reached out to the team building Scion and Antique to learn more about how Scion works. Here's what they told me:

      Technical details

      The design of Scion is pretty simple: stand up "server" nodes (that contain the whole repository), store changesets inside of Google Spanner (Google's distributed, highly available database) and blobs (large files) in the highly durable Google Cloud Storage:

      Scion's architecture, at a high level

      I asked Nick G - one of the authors of the original blog posts - about additional details and here's what he told me:

      • Rust : the language that Scion's server and client are written in.
      • Go + React: Antique, Anthropic's new code review and code management platform has its backend in Go and frontend written in React. It works nicely with Scion.
      • More resilient replication strategy : by default, Google Spanner offers multi-zone replication with three replicas. Anthropic has increased the number of replicas (they didn't tell me the exact number, but an educated guess could be five or more replicas), and switched to multi-region replication. All these changes make sense, given how critical code is and that it 's sensible to reduce the likelihood of losing any data - even at the cost of higher write latencies.
      • Backups : on top of replication, Anthropic keeps full backups of the database and soft deletes on the blob storage where file contents live. Spanner's point-in-time recovery also lets Anthropic restore from a bad write. Smart!

      Scaling is an interesting topic. I asked Nick if the system autoscales or scales manually. He told me:

      "Every component can autoscale, but so far it hasn't needed to, even as our merge volume grew more than 10x this year. The data is content-addressed and never changes once it's stored, so the caching tiers do most of the work."

      A team of seven engineers builds and maintains all of this :

      • Four worked on the core Scion server and client
      • Three were split between building code search, merge queues, etc.

      100% of Anthropic 's monorepo has moved off Git. This was no small feat to pull off! Nick gave me more details about the migration:

      "The migration was not simple, but Claude was instrumental in getting it done. It's also 'self-healing' in a way: if we get all the important use cases migrated and have something like 99% coverage, we can just force the cutover and Claude can help us fix anything that actually mattered.

      100% of our monorepo is off of git. A few smaller repos that were never in the monorepo are migrating now, and they're much simpler.

      All of our community resources continue to live on GitHub: skills, plugins, Claude Code's public repo, etc. And last week we launched OSS Scanner, which gives open-source projects free security audits using our strongest models (inspired by Google's OSS- Fuzz)."

      Big Tech moved off Git long ago

      My take is that Anthropic has "Big Tech problems" much earlier than most of Big Tech had to tackle them. Anthropic employs around 3,500 staff, but their coding output - thanks to each person using around 10 agents all the time - is closer to that of a tech company with 35,000-70,000 staff! That's a Meta or Google-sized company by the number of engineers.

      Google and Meta have long since moved off Git because it did not scale for them.

      Google built its own version control that took inspiration from Perforce. Git itself was created by Linus Torvalds in 2005, seven years after Google was founded. So git was not an option for Google to use in the early years: the company chose Perforce instead. It was around 2011-2012 that Google had ran into scaling issues with Perforce and built its own source control system called 'Piper.' It's also a centralized version control model and still works well enough for the search giant. It's no surprise to know that Piper was inspired by Perforce, and Google built Piper to be more performant for their use cases than Perforce was. We covered more on Google 's internal stack in the deepdive Inside Google 's Engineering Culture .

      Meta found that git and other systems could not scale as needed, and so built 'Sapling.' Meta initially moved over to Mercurial, and then custom- built and open sourced Sapling for itself. As the company shared at the time:

      "Sapling began 10 years ago [around 2012] as an effort to make Meta's monorepo scale in the face of ever-increasing engineering growth. Publicly available source control systems were not, and still are not, capable of handling repositories of this size. Instead of moving away from the monorepo and sacrificing engineering velocity, we decided to build the source control system we needed.

      Along the way we realized there were also large opportunities to increase developer velocity by improving the source control experience. By investing in new UX, we've made it possible for even new engineers to understand their repository and do things that were previously only possible for power users."

      Sapling itself is more of a client-server architecture. From the documentation:

      "Sapling started from Mercurial as a distributed source control system, it then transitioned to a client-server architecture to solve the challenges. The server can utilize distributed storage and pre-build various kinds of indexes to provide more efficient operations.

      While Sapling is less "distributed", we tried to make the difference transparent to the user. For example, our lazy commit graph implementation does not require extra commands to "deepen" the graph. The user sees the full history.

      That said, we do drop support of pulling from a lazy repo. Commit cloud covers these use-cases."

      Did Anthropic secretly rip off Sapling 's and Mononoke server

      I asked Anthropic why it doesn't open source Scion. Nick G's reply:

      "Mostly bandwidth! Even a no-support code drop takes a lot of work to do well. We have a small team building and running Scion. While the principles we used to build it are durable, the underlying code changes very frequently. For example, we're still removing git-compatibility layers we only needed for the migration. We'd rather put that time into sharing what we learned, and as the post says, into working with GitHub, GitLab and the OSS community on scaling git.

      To emphasize that point: most teams don't need to leave git! But we think there are things git could benefit from, mainly change sets, derived data, and the checkout protocol. Our goal was to inspire conversation and collaboration around those ideas."

      The explanation, on one end, makes sense. On the other, Meta themselves also emphasized how most teams don't need to leave git, and still open sourced Sapling for anyone to use, or take inspiration from.

      One key component of Sapling is Monoke: the also open source server meant to scale up accepting thousands of commits every hour, across millions of files, written in Rust.

      Could have Anthropic avoided open sourcing Scion, because it might have shown how much they copied from existing open source projects? The creator of Monoke wrote a post accusing of the Anthropic team of ripping off Monoke -- and the Bonsai data model -- writing:

      "This [Scion] was a ripoff. My post yesterday was trying to be as charitable as possible given what I knew, and in particular that the similarity to Mononoke was mostly unintentional and the lack of credit was the result of not doing due diligence. However, after publishing the post I privately received confirmation that Scion intentionally and blatantly ripped off Mononoke, and in particular that there was overlap in personnel. There is no chance that this was an unintentional homage. This is something I had a hunch about but was not comfortable saying yesterday, given what I knew back then.

      The resemblance is much deeper than just the notion of derived data. Some people pointed out that derived data is just an index, which is a well-known concept. I want to clarify that derived data was merely the most striking resemblance. It goes much deeper than that, and extends to the entire data model, as well as a number of the structures built around it."

      Anthropic did not give credit to Monoke in their original post, and only added a small attribution after the complaint.

      To be clear, the point of open source is that you can do what you want with the software without much limitations (save for what the license contains): but it's poor form that it took a public complaint for Anthropic to admit that the clever data structure they presented in their blog post heavily derived for an existing and open source data strucutre.

      Will central VCs stay a niche, or expland beyond Big Tech?

      Big Tech has preferred centralized version control systems (VCS), and I wonder how niche of a trend central VCSs will remain. As we've seen since well before AI, some of the largest tech companies dropped git because they did not like the performance degradation from offline support they no longer need.

      My question is that even with agents, how many companies will see git "break" similarly to how it has at Anthropic? When this happens, how many will find git's mirroring functionality inadequate for their own needs?

      There's a new batch of vendors positioning themselves as git-compatible version control solutions built for AI scale: Entire, founded by GitHub's last CEO, Thomas Dohmke (a current podcast season sponsor), Cursor Origin by SpaceX, and Code Storage by The Pierre Company. At the same time, GitHub itself seems to be investing a lot more in making its platform more reliable and scalable.

      My hunch is that very few companies will go through the trouble of building yet another source control system. In this way, Anthropic reminds me a bit of Google, which has been known to build custom internal systems which are not publicly available, to address the company's internal needs. This can be disorienting for Google engineers after they leave the company and find they've become out of touch with industry-standard tools.

      ---

      Read the full issue of The Pulse this is from, or check out this week 's The Pulse. This week's issue covers:

      1. Do we need to rethink software security because of AI? Half a dozen of high-profile security incidents and breaches on a single day: and many of them are connected to AI (or sped up because of it). Attackers are gaining unfair advantages with AI, and defenders will have to react.
      2. Is Anthropic 's new version control system "a rip off"? The creator of Mononoke (an open source, high throughput version control server) accused Anthropic for ripping off their design, and not giving credit, presenting their work like it was novel. Not a good look on the AI lab.
      3. Industry Pulse. Saudi Arabia made a "problematic" offer to pay alleged OpenAI spy's bail, Shopify builds tooling for self-healing software, Foursquare's sale disappoints, Claude Code gets a major speed boost with gzip, and more.
      4. Predictions on the future of software development. Some bold predictions from software engineer and Amp cofounder Thorsten Ball, like how open source doesn't make sense in its current form anymore.
   8. 🔗 r/Harrogate Anyone know of any work/laptop friendly cafes? rss

      Or shall I just stick with Starbucks or Nero

      Obviously not for taking the piss but for sitting with a laptop for 2 hours at a time maybe

      submitted by /u/sophietheadventurer
      [link] [comments]

   9. 🔗 Console.dev newsletter Sponsor: Falconer rss

      Monitor your docs like your code. Falconer finds and fixes doc issues before they mislead agents.

      Visit Falconer

   10. 🔗 Console.dev newsletter Pele rss

       Mermaid diagram render.

       What we like: Renders Mermaid syntax to SVG. Colors and fonts are customizable through CSS. Zero dependencies. Responsive layouts and very fast render times (under 1ms).

       What we dislike: Doesn’t support all diagram types or Mermaid plugins.

   11. 🔗 Console.dev newsletter KiviDB rss

       Redis/Valkey alternative.

       What we like: Redis-compatible protocol, including search, vectors, and Lua scripting. Commands run on every core rather than one thread. Claims faster performance than Redis, including better p99 latency. Runs on a different port by default. Written in Rust.

       What we dislike: Licensed under AGPL.

   12. 🔗 Console.dev newsletter Sponsor: BuildKite rss

       Better CI

       Visit BuildKite

   13. 🔗 backnotprop/plannotator v0.28.26 release

       Follow @plannotator on X for updates

       Missed recent releases? Release | Highlights
       ---|---
       v0.28.25 | Re-ask open questions, delivery ticks on the list, a count of new messages on the tab, right-click a thread, click Inbox to refresh
       v0.28.24 | A new look for the Inbox, Send now, tag agents, comment on an agent's message, much smaller reads for agents, links in HTML pages
       v0.28.23 | Inbox replies reach sessions with background subagents, dictated text no longer goes missing, 👍 Looks good reaches the agent, notifications that never fail silently
       v0.28.22 | 👍 Looks good, full view for files, one viewer for a thread's images and files, every session prints its URL, PLANNOTATOR_BROWSER=none opens nothing
       v0.28.21 | Message an agent from the Inbox, video attachments, Open in for attachments, Code / Tests / Generated in code review, writes from other websites refused
       v0.28.20 | Inbox search (⌘K), real folder names for projects, data files open in the code view, word-only replies leave questions open
       v0.28.19 | Ask this session in T3 Code, folder sessions load shared stylesheets and images, the agent note asked once per agent, Copy connect prompt
       v0.28.18 | plannotator inbox connects your agents, agents are told when to use the Inbox, rendered Markdown in code review, Inbox Settings in sections
       v0.28.17 | The Inbox on iPads and narrow windows, the reply bar no longer cuts off "Keep open", a Pi crash on /reload fixed
       v0.28.16 | The Inbox on a phone, a doorbell for new questions, Mark read, step through a thread's files, replies when the asking session ended
       v0.28.15 | Long Inbox threads fold to what is new, "Skipped N questions" replies, Inbox list and sidebar fixes
       v0.28.14 | Agents can replace an earlier question, comment on a guided review in the Inbox, issue numbers link to the repository

       What's New in v0.28.26

       Action items and reply drafts in the Inbox, one decision button for plan review, Enter to save a comment, a custom code font, and many fixes. 35 PRs, 9 of them from 8 outside contributors, 5 of whom are first-timers.

       Plannotator Inbox

       Action items

       An agent can ask you to go do something: run a command, sign in somewhere, check a page. It shows as a card in the thread with Done , Can't do it and Add note , and your answer goes back to the agent.

       • #2059

       Reply drafts

       What you type in a reply box is kept per thread. It comes back when you reopen the thread, after a reload, and after a restart. A thread with an unsent draft is marked Draft in the list.

       • #2028

       Replies to a busy agent go in on their own

       If the agent is in a long turn, the line under your reply shows how long it has waited, and after 5 minutes the reply goes into the running turn by itself, as if you'd pressed Send now.

       • #2056

       Smaller changes

       • A Send skips a question only when you press Skip. Questions you leave alone stay open. #2058
       • Answers you pick while writing a reply show in the reply box right away. #2051
       • A skipped question keeps its note in the reply. #2034
       • Several Inbox tabs share one connection to the Inbox. #2057
       • Subjects stay on one line , and stray tool-call text never becomes a title. #2053
       • A thread that fails to load tries again and says so. #2054
       • Faster over your tailnet : the window is sent compressed. #2042
       • Long issue numbers link as issues , not colour swatches. #2040
       • Restart help leads with/reload-plugins. #2035
       • Works behind a local reverse proxy (nginx, Caddy). #2060

       Plannotator

       One decision button for plan review

       Plan review's header now works like annotate and code review. With nothing to send it shows Approve. Once you add comments it becomes Send Feedback. Other choices, such as Request changes or Approve with notes, are under the arrow.

       • #2055, closing #1057

       Enter to save a comment

       Turn on Settings → General → Enter saves a comment , and Enter saves while Shift+Enter adds a new line. It's off by default.

       • #2048, closing #1934

       Your own code font

       Settings → Display → Code Font → Custom… takes the name of any font on your machine for code review.

       • #855, closing #851

       Start a new Ask AI chat

       A New chat button clears the Ask AI panel and starts fresh, in plan review, annotate and code review.

       • #2046, closing #1981

       Jump between changes in code review

       N and P jump to the next and previous change. Commenting from the gutter now covers every line you selected, not just the one you clicked.

       • #1550, closing #1543 and #991, by @FNDEVVE

       Smaller changes

       • A code review an agent waits on hears your Approve (Claude Code). #2047
       • Annotate picks up a file changed on disk in its version diff. #2049
       • A plan reviewed across midnight keeps its versions. #1681 by @aomalov
       • Images in a folder session load from the open document's folder. #2033 by @xiaofeilovecoding
       • Sidebar shortcuts stay visible next to the Agent TUI. #1019 by @leoreisdias
       • Afile.ts:42 link opens at line 42. #1909 by @Totopo27
       • Triple-click no longer highlights into the next line. #1408 by @dca123
       • Ticking a Guided Review section marks its files viewed. #2044
       • Very large diffs from git textconv are never drawn. #2041
       • Pi: review opened and closed events, and long checklists keep the next item in view. #2050
       • OpenCode: the agent-switch choice is saved, and Ask AI no longer hangs. #2045, #1413 by @danowicz
       • Claude Code Team/Enterprise: a plan is approved once, not twice. #2043
       • The install script works on machines withoutgh. #1995 by @viniciusestevam

       Install / Update

       macOS / Linux:

       curl -fsSL https://plannotator.ai/install.sh | bash
       

       Windows:

       irm https://plannotator.ai/install.ps1 | iex
       

       Claude Code Plugin: The plugin and the plannotator binary update separately, so run the install script above as well. In a terminal:

       claude plugin marketplace update plannotator
       claude plugin update plannotator@plannotator
       

       Then restart Claude Code. Inside Claude Code, run /plugin marketplace update plannotator, then open /plugin → Installed → plannotator → Update now.

       Pi:

       pi update --extensions
       

       OpenCode: Re-run the install script above. It now also clears the OpenCode 2 plugin cache.

       What's Changed

       • feat(review): custom code font support by @backnotprop in #855
       • feat(annotate): keep sidebar shortcuts visible with Agent TUI by @leoreisdias in #1019
       • Fix triple-click highlight bleed into the next line by @dca123 in #1408
       • fix(ai): keep OpenCode Ask AI subscribed before prompting by @danowicz in #1413
       • fix(review): full-range gutter annotations and next/prev hunk jump by @FNDEVVE in #1550
       • fix(plan): keep the version chain when a review spans midnight by @aomalov in #1681
       • fix(ui): scroll and highlight referenced line in code file popout by @Totopo27 in #1909
       • Installers: resolve latest from the releases/latest redirect when the API fails by @viniciusestevam in #1995
       • Inbox Board (1/3): card records and the card call by @backnotprop in #2026
       • Inbox: reply drafts and the Draft label by @backnotprop in #2028
       • fix: resolve folder images from the active document by @xiaofeilovecoding in #2033
       • Inbox: keep a skipped question's note in the reply by @backnotprop in #2034
       • Inbox: lead with /reload-plugins, fold the manual restart by @backnotprop in #2035
       • CI: pin Linux runners to ubuntu-24.04 by @backnotprop in #2036
       • Inline markdown: digit-only #refs link as issues, not colour swatches by @backnotprop in #2040
       • Review: never render a textconv diff past the size cap by @backnotprop in #2041
       • Inbox: serve the window compressed over the tailnet by @backnotprop in #2042
       • Claude Code mod: one plan approval when the plugin guard skips the mod's hook by @backnotprop in #2043
       • Guided Review: ticking a section marks its files viewed by @backnotprop in #2044
       • OpenCode: remember the agent-switch choice in config.json by @backnotprop in #2045
       • Ask AI: start a new chat by @backnotprop in #2046
       • Code review: gate, so a bare Approve reaches the agent by @backnotprop in #2047
       • Comments: opt-in Enter to save by @backnotprop in #2048
       • Annotate: a disk change shows in the version diff by @backnotprop in #2049
       • Pi: session events and a checklist that keeps the next item in view by @backnotprop in #2050
       • Inbox: answers picked while writing a reply show live in the reply box by @backnotprop in #2051
       • Tests: fix main's DOM allowlist failure by @backnotprop in #2052
       • Inbox: one-line subjects; leaked tool-call text never shows as a title by @backnotprop in #2053
       • Inbox: read a thread again when its first read fails, and say so by @backnotprop in #2054
       • Plan review: one adaptive decision control by @backnotprop in #2055
       • Inbox: Undelivered replies show their wait and go in by themselves after 5 minutes by @backnotprop in #2056
       • Inbox: tabs share one event connection by @backnotprop in #2057
       • Inbox: a Send skips a question only when you press Skip by @backnotprop in #2058
       • Inbox: action items an agent needs you to go do by @backnotprop in #2059
       • fix(inbox): allow loopback x-forwarded-for from local reverse proxies by @Totopo27 in #2060

       New Contributors

       • @viniciusestevam made their first contribution in #1995
       • @xiaofeilovecoding made their first contribution in #2033
       • @aomalov made their first contribution in #1681
       • @danowicz made their first contribution in #1413
       • @Totopo27 made their first contribution in #1909

       Contributors

       • @FNDEVVE: full-range gutter comments and hunk jumps in code review.
       • @leoreisdias: sidebar shortcuts beside the Agent TUI.
       • @dca123: the triple-click highlight fix.
       • @Totopo27: line-accurate code links, and the Inbox behind a local reverse proxy.
       • @aomalov: reported and fixed plans that lost their versions at midnight.
       • @danowicz: the OpenCode Ask AI hang.
       • @xiaofeilovecoding: folder images from the open document.
       • @viniciusestevam: reported and fixed the installer without gh.

       Thanks to everyone who reported issues or asked for features in this release:

       • @solalbaudoincs (#1867), @akaralar (#851), @clauxx (#1934), @alexanderkreidich (#991), @andrew-corlann (#1543), @levyashvin (#1057), @kekel87 (#1907), @ppommer (#1981)
       • @RobertoArtiles (#1784), @PassionZale (#2006), @viniciuskneves (#2037), @michaelmior (#1412), @jumski (#1589), @sergdort (#1390), @oronbz (#1786), @ericknyoto (#2007), @zane668 (#2032), @timmo001 (#1932)

       Full Changelog : v0.28.25...v0.28.26

   14. 🔗 pydantic/monty v1.3.0 - 2026-10-21 release

       What's Changed

       • Decode file URLs in WASM and browser test aliases by @Pybsama in #1007
       • test: check packed WASM declarations in smoke tests by @Pybsama in #1004
       • Fix re.match() and re.fullmatch() for (?x) patterns that end in a comment by @Likheet in #1046
       • close further missing dunder gaps by @davidhewitt in #1074
       • tidy up some looseness in the HeapReader::protect API by @davidhewitt in #1076
       • perf: avoid intermediate string id allocation on keyword call dispatch by @gabrielhsc95 in #1080
       • Match CPython's odd padding split in str.center and bytes.center by @RaphaelFakhri in #1085
       • experiment with making bytecode from builtins by @davidhewitt in #841
       • implement PyValue abstraction to avoid InternStr / Str diffs etc by @davidhewitt in #1050
       • Bound AST depth before the type checker walks it by @rewitt94 in #930
       • bump deps for CA compromise by @davidhewitt in #1096
       • release: 1.3.0 by @davidhewitt in #1097
       • fix npm smoke test by @davidhewitt in #1099

       New Contributors

       • @Pybsama made their first contribution in #1007
       • @RaphaelFakhri made their first contribution in #1085

       Full Changelog : v1.2.0...v1.3.0

   15. 🔗 smol-machines/smolvm smolvm v1.31.2 release

       What's Changed

       • chore(nix): bump flake to 1.31.0 by @github-actions[bot] in #1917
       • Never lower a branch source's memory ceiling below what its cgroup still holds by @BinSquare in #1921
       • chore(nix): bump flake to 1.31.1 by @github-actions[bot] in #1923
       • Fix flaky branchpoint lease test by @BinSquare in #1918
       • Let machine monitor flags override the Smolfile health settings by @RaphaelFakhri in #1920
       • Give a new disk volume the image's ownership and bind nested volumes after their parents by @BinSquare in #1870
       • ci: run every Linux job on smol machines by @BinSquare in #1916
       • Change ports live on machines without virtio-net through a vsock port forwarder by @BinSquare in #1875
       • Add Chinese, Japanese and Korean READMEs by @BinSquare in #1871
       • Pass the guest path to ns-file and stage on scratch for streamed container uploads by @Vishv07 in #1925
       • Isolate filesystem unit tests from the CI runner overlay by @BinSquare in #1927
       • agent: unit tests never resolve paths through the machine they run on by @BinSquare in #1926
       • Checkpoint a source frozen as a branch base without resuming it, so its branches can move to another node by @BinSquare in #1928
       • Keep cache disk bases within a byte budget, evicting the least recently used by @BinSquare in #1930
       • Bump smolvm to 1.31.2 by @BinSquare in #1929
       • Put /tmp on disk, regrow /dev/shm after a RAM grow, match GitHub runner limits and LANG by @BinSquare in #1931
       • Record why a machine's VMM ended, OOM kill and seccomp included by @BinSquare in #1884
       • Fix inherited disk-chain compaction by @BinSquare in #1933
       • Move a live-published host port to another guest port without rebinding it, and close removed ports before the change returns by @BinSquare in #1935
       • Unpack a .smolmachine once per pack on macOS and clone it for each machine, and let no create leave its data behind when it fails or its client disconnects by @BinSquare in #1934
       • Keep a machine's disk durability across checkpoint restore and let machine update change it by @BinSquare in #1932
       • Answer a branch at the disk chain limit with 409 instead of 500 by @BinSquare in #1936

       New Contributors

       • @github-actions[bot] made their first contribution in #1917
       • @RaphaelFakhri made their first contribution in #1920

       Full Changelog : v1.31.0...v1.31.2

   16. 🔗 Ampcode News Self-Hosted Orbs rss

       You can now self-host orbs. You provide the compute and Amp turns it into orbs.

       If you have compute that can

       • quickly start new machines
       • put them to sleep and resume them equally fast
       • keep them around for a long time
       • scale them to zero, so no one has to worry about having a lot of them sleeping

       then you are now able to replicate the orb experience within your own infrastructure.

       How It Works

       You run amp orb provider inside your infrastructure. The orb provider then reaches out to Amp and waits for requests to spawn, pause, or delete orbs. Like this:

       

       How you satisfy those requests is up to you, because amp orb provider will dispatch the requests for orb operations (spawn to create or resume orbs, pause, and delete) to a program that you provide, like so:

       $ amp orb provider ./dispatch.sh
       

       In that program, you can do whatever works best for your infrastructure. Here are some illustrative examples:

       Docker E2B K8s Apple containers Modal Vercel Daytona exe.dev

       #!/usr/bin/env bash
       # dispatch.sh
       set -euo pipefail
       
       case "$ORB_OPERATION" in
           spawn)
               docker start "$ORB_ID" 2>/dev/null ||
                   docker run --platform linux/amd64 -d --name "$ORB_ID" \
                       "$ORB_IMAGE" sleep infinity
               docker exec -d --env ORB_TOKEN "$ORB_ID" amp orb bootstrap
               ;;
           pause)
               docker stop "$ORB_ID"
               ;;
           delete)
               docker rm -f "$ORB_ID"
               ;;
       esac
       

       Install the E2B CLI and the e2b package, set E2B_API_KEY, and build a template:

       echo 'FROM us-central1-docker.pkg.dev/amp-prod-0/amp-orb/amp-orb:latest' \
           > e2b.Dockerfile
       e2b template create amp-orbs --dockerfile e2b.Dockerfile \
           --cpu-count 4 --memory-mb 8192 --ready-cmd true
       export E2B_TEMPLATE=amp-orbs
       

       #!/usr/bin/env node
       // dispatch.mjs
       import { Sandbox } from 'e2b'
       
       const {
           ORB_OPERATION, ORB_ID, ORB_TOKEN, AMP_URL, E2B_TEMPLATE,
       } = process.env
       const metadata = { orbId: ORB_ID }
       const [existing] = await Sandbox.list({
           query: { metadata, state: ['running', 'paused'] },
       }).nextItems()
       
       if (ORB_OPERATION === 'spawn') {
           const timeoutMs = 60 * 60 * 1000
           const sandbox = existing
               ? await Sandbox.connect(existing.sandboxId, { timeoutMs })
               : await Sandbox.create(E2B_TEMPLATE, {
                   metadata, timeoutMs, lifecycle: { onTimeout: 'pause' },
               })
           const envs = { ORB_TOKEN }
           if (AMP_URL) envs.AMP_URL = AMP_URL
           const bootstrap = await sandbox.commands.run('amp orb bootstrap', {
               user: 'user', envs, background: true, timeoutMs: 0,
           })
           await bootstrap.disconnect()
       } else if (ORB_OPERATION === 'pause' && existing) {
           await Sandbox.pause(existing.sandboxId)
       } else if (ORB_OPERATION === 'delete' && existing) {
           await Sandbox.kill(existing.sandboxId)
       }
       

       #!/usr/bin/env bash
       # dispatch.sh
       set -euo pipefail
       export PATH="/usr/local/bin:/opt/homebrew/bin:$PATH"
       
       # "$ORB_IMAGE" is the Amp orb image.
       
       ids=$(container list --all --quiet)
       exists() { grep -Fxq "$ORB_ID" <<<"$ids"; }
       
       case "$ORB_OPERATION" in
           spawn)
               if exists; then
                   container start "$ORB_ID"
               else
                   container run --detach --init --rosetta \
                       --platform linux/amd64 --cpus 4 --memory 8G \
                       --name "$ORB_ID" "$ORB_IMAGE" sleep infinity
               fi
               # A bare --env NAME copies the value from the host.
               container exec --detach --env ORB_TOKEN --env AMP_URL \
                   "$ORB_ID" amp orb bootstrap
               ;;
           pause)
               if exists; then
                   container stop "$ORB_ID"
               fi
               ;;
           delete)
               if exists; then
                   container delete --force "$ORB_ID"
               fi
               ;;
           *)
               exit 1
               ;;
       esac
       

       #!/usr/bin/env python3
       # dispatch.py
       import os
       
       import modal
       
       # Needs `pip install modal` plus MODAL_TOKEN_ID and MODAL_TOKEN_SECRET.
       APP = "amp-orbs"
       app = modal.App.lookup(APP, create_if_missing=True)
       snapshots = modal.Dict.from_name("amp-orb-snapshots", create_if_missing=True)
       orb_id = os.environ["ORB_ID"]
       
       try:
           sandbox = modal.Sandbox.from_name(APP, orb_id)
       except modal.exception.NotFoundError:
           sandbox = None
       
       match os.environ["ORB_OPERATION"]:
           case "spawn":
               if sandbox is None:
                   # Modal has no pause, so resume from the last snapshot.
                   snapshot = snapshots.get(orb_id)
                   if snapshot:
                       image = modal.Image.from_id(snapshot)
                   else:
                       image = modal.Image.from_registry(os.environ["ORB_IMAGE"])
                   sandbox = modal.Sandbox.create(
                       "sleep", "infinity", app=app, name=orb_id, image=image,
                       cpu=4, memory=(16384, 16384), timeout=24 * 60 * 60,
                   )
               # Modal execs run as root; point bootstrap at the image user's home.
               bootstrap = "setsid amp orb bootstrap </dev/null >/dev/null 2>&1 &"
               sandbox.exec(
                   "bash", "-c", bootstrap,
                   env={
                       "ORB_TOKEN": os.environ["ORB_TOKEN"],
                       "AMP_URL": os.environ.get("AMP_URL"),
                       "HOME": "/home/user", "USER": "user",
                   },
               ).wait()
           case "pause":
               if sandbox:
                   image_id = sandbox.snapshot_filesystem(timeout=120).object_id
                   snapshots[orb_id] = image_id
                   sandbox.terminate()
           case "delete":
               if sandbox:
                   sandbox.terminate()
               snapshots.pop(orb_id, None)
       

       #!/usr/bin/env node
       // dispatch.mjs
       import { APIError, Sandbox, Snapshot } from '@vercel/sandbox'
       
       const { ORB_OPERATION, ORB_ID, ORB_IMAGE, ORB_TOKEN, AMP_URL } = process.env
       const credentials = {
           token: process.env.VERCEL_TOKEN,
           teamId: process.env.VERCEL_TEAM_ID,
           projectId: process.env.VERCEL_PROJECT_ID,
       }
       
       if (ORB_OPERATION === 'spawn') {
           const sandbox = await Sandbox.getOrCreate({
               ...credentials,
               name: ORB_ID,
               // Copy Amp's image to VCR, then set ORB_IMAGE to its VCR URL.
               image: ORB_IMAGE,
               resources: { vcpus: 4 },
               timeout: 60 * 60 * 1000,
               persistent: true,
               snapshotExpiration: 0,
               keepLastSnapshots: { count: 1, expiration: 0, deleteEvicted: true },
           })
           const setup = await sandbox.runCommand({
               cmd: '/bin/bash',
               args: ['-c', 'hostname localhost && mkdir -p /vercel/sandbox'],
               sudo: true,
           })
           if (setup.exitCode !== 0) throw new Error(await setup.stderr())
           await sandbox.runCommand({
               cmd: '/usr/bin/setpriv',
               args: [
                   '--reuid=user', '--regid=user', '--init-groups', '--',
                   '/usr/bin/env', `ORB_TOKEN=${ORB_TOKEN}`,
                   ...(AMP_URL ? [`AMP_URL=${AMP_URL}`] : []),
                   'HOME=/home/user', 'USER=user', '/bin/bash', '-lc',
                   'exec amp orb bootstrap',
               ],
               sudo: true,
               detached: true,
           })
       } else if (ORB_OPERATION === 'pause' || ORB_OPERATION === 'delete') {
           try {
               const sandbox = await Sandbox.get({
                   ...credentials, name: ORB_ID, resume: false,
               })
               if (ORB_OPERATION === 'delete') {
                   if (sandbox.status === 'running') await sandbox.stop()
                   for await (const saved of await sandbox.listSnapshots()) {
                       if (saved.status !== 'created') continue
                       const snapshot = await Snapshot.get({
                           ...credentials, snapshotId: saved.id,
                       })
                       await snapshot.delete()
                   }
                   await sandbox.delete()
               } else if (sandbox.status === 'running') await sandbox.stop()
           } catch (error) {
               if (!(error instanceof APIError && error.response.status === 404)) {
                   throw error
               }
           }
       }
       

       #!/usr/bin/env python3
       # dispatch.py
       import os
       from uuid import uuid4
       from daytona import (
           Daytona, DaytonaNotFoundError, CreateSandboxFromImageParams,
           Resources, SessionExecuteRequest, SandboxState,
       )
       
       daytona = Daytona()
       operation = os.environ['ORB_OPERATION']
       try:
           sandbox = daytona.get(os.environ['ORB_ID'])
       except DaytonaNotFoundError:
           sandbox = None
       
       if operation == 'spawn':
           if sandbox is None:
               sandbox = daytona.create(CreateSandboxFromImageParams(
                   name=os.environ['ORB_ID'], image=os.environ['ORB_IMAGE'],
                   os_user='user', resources=Resources(cpu=4, memory=8, disk=10),
                   auto_stop_interval=0, auto_delete_interval=-1,
               ), timeout=240)
           elif sandbox.state != SandboxState.STARTED:
               sandbox.start()
           env = {key: os.environ[key] for key in ('ORB_TOKEN', 'AMP_URL')
                  if key in os.environ}
           sandbox.update_env(env, unset=['AMP_URL'])
           session = str(uuid4())
           sandbox.process.create_session(session)
           sandbox.process.execute_session_command(session, SessionExecuteRequest(
               command="bash -lc 'exec amp orb bootstrap'", run_async=True,
           ))
       elif operation == 'pause' and sandbox:
           if sandbox.state == SandboxState.STARTED:
               sandbox.stop()
       elif operation == 'delete' and sandbox:
           sandbox.delete()
       

       #!/usr/bin/env bash
       # dispatch.sh
       set -euo pipefail
       
       # Pause/resume currently requires access enabled by exe.dev support.
       status=$(ssh exe.dev ls "$ORB_ID" --json |
           jq -r --arg id "$ORB_ID" '.vms[] | select(.vm_name == $id) | .status')
       
       case "$ORB_OPERATION" in
           spawn)
               if [[ -z "$status" ]]; then
                   ssh exe.dev new --name="$ORB_ID" --image="$ORB_IMAGE" \
                       --cpu=2 --memory=8G --no-email
               elif [[ "$status" == paused ]]; then
                   ssh exe.dev resume "$ORB_ID"
               fi
               {
                   printf 'export ORB_TOKEN=%q\n' "$ORB_TOKEN"
                   if [[ -n "${AMP_URL:-}" ]]; then
                       printf 'export AMP_URL=%q\n' "$AMP_URL"
                   fi
                   cat <<'BOOTSTRAP'
       sudo -u user --preserve-env=ORB_TOKEN,AMP_URL bash -lc \
           'cd "$HOME"; nohup amp orb bootstrap </dev/null >.amp-bootstrap.log 2>&1 &'
       BOOTSTRAP
               } | ssh "$ORB_ID.exe.xyz" bash -s
               ;;
           pause)
               if [[ "$status" == running ]]; then
                   ssh exe.dev pause "$ORB_ID"
               fi
               ;;
           delete)
               if [[ -n "$status" ]]; then
                   ssh exe.dev rm "$ORB_ID"
               fi
               ;;
       esac
       

       Use Amp's Helm chart to run orbs on GKE, EKS, or AKS. Under the hood, it runs amp orb provider with a supplied dispatch program that handles spawning, pausing, and deleting orbs. You don't need to write a dispatch script yourself.

       1. Create a custom orb provider in your Amp workspace and copy its token.
       2. Prepare a dedicated cluster with worker nodes and snapshot storage. Paused orbs are saved to storage and can resume on another worker node.
       3. Download the Kubernetes setup files. The ZIP includes gke.md, eks.md, and aks.md with the setup and Helm commands for each cloud, plus Terraform examples. Use the instructions for your cloud to install the chart and test your first orb.

       These examples use Amp's pre-built ORB_IMAGE, which includes the Amp CLI and other dependencies. You can use a different Linux image as long as you can start amp orb bootstrap in it (and it has the dependencies for other features). That process connects the orb to Amp so Amp can set up the environment and run the agent's tools.

       Once you have your dispatch program, go to your workspace settings (individuals can create a workspace for free), add a Custom Orb Provider, copy the token, and run amp orb provider:

       $ chmod +x dispatch.sh
       $ export AMP_ORB_PROVIDER_TOKEN="<copied-token>"
       $ amp orb provider ./dispatch.sh
       

       Once that runs, open ampcode.com or the Amp macOS or iOS applications and create a new thread. Expand Orb and choose your provider under Self-Hosted.

       

       And then submit your prompt. Amp will send a request to your provider to spawn an orb, clone your repository, run your setup files, and start the agent.

       And thus begins, as they say, orbin' time. Self-hosted.

       You Probably Shouldn't Self-Host Orbs

       All that said: you probably shouldn't self-host orbs.

       We built self-hosted orbs for enterprises that can't use the orbs we host, because regulations might restrict where their code runs, because they need access to internal networks, or because they need custom hardware attached.

       If you're on an Enterprise plan, let us know and we'll help you set it up.

       That's why the interface is so open: we want to support all the infrastructure our enterprise customers might have, as long as it meets the qualitative requirements above (fast-to-start, resumable machines that scale to zero, etc.). But that also means we only support our end of the contract, not every possible piece of infrastructure you can plug in.

       Pricing

       Self-hosted orbs are free for individuals and teams. Enterprises will be charged standard orb pricing starting October 29. Until then, self-hosted orbs are free for every workspace.

       Getting Started

       For more information on self-hosted orbs and how to run self-hosted orbs on Kubernetes, see the documentation.

2. October 21, 2026
   1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-10-21 rss

      IDA Plugin Updates on 2026-10-21

      New Releases:

      • oh-my-dump Oh My Dump v1.0.17 for IDA Pro 9.x
      • oh-my-pi v18.12.6
      • oh-my-pi v18.12.5
      • pyrrha v2.1.0—HackLu version: Imports and Thunks

      Activity:

      • capa
        • 2bdf7a47: Sync capa rules submodule
      • ida-cli
        • 1a885505: Isolate reused runtime evidence and serialize helper test observations
        • da5b7d90: Normalize the launch grant root through system symlink prefixes
        • 219fd999: Remove obsolete absence-settlement descriptions and dead scan helper
        • 5dde33db: Witness complete journal retirement before releasing the late worker
        • a173256b: Preserve authorization fences after confirmed shutdown in cleanup gui…
        • 72b01ed6: Correct the documented five-patch chain enumeration
        • 28571682: Record the actual late-worker denial exit code in regression evidence
        • 3537f5e6: Add an exact helper-signed before-Rust-ACK W1 test barrier
        • d3d5c37b: Reject legacy absence-only facts at the target journal boundary
        • 917f8e07: Cover unreadable argv with a complete live process status
        • 6b6d4231: Prove late workers cannot open after revocation and document upgrade …
        • 8e9c4efc: Remove the obsolete elapsed exec margin from launch settlement
        • 338ea084: Settle unclaimed launches using atomic revocation instead of process …
        • 8964f207: Gate SDK worker IDB access on a durable revocable launch permit
        • 51179df8: Document feasibility and durable launch authorization design
        • adb16e4f: Align bridge entrance refusal retry advice with recovery metadata
        • ae36b935: Restrict bridge-loss retries to whole-request entrance refusals
        • 7b238081: Let the unarmed bridge-loss test settle before the next case opens
        • 142be433: Let a daemon with a lost Nexus bridge leave by itself and let the CLI…
        • 55bb8c87: Settle a signed launch whose owner never existed after the bridge was…
      • ida-domain
        • 2e956294: Publish to PyPI with PEP 740 attestations (#140)
      • ida-nexus
        • a5fe4f0a: Merge pull request #72 from HexRaysSA/feat/attribute-error-suggestions
      • idalib
        • 48e57f76: fix: require Function, Segment, and CFunction to be dropped bef…
      • mcrit-plugin
        • 38f9bac7: Make the Ghidra tab headers clickable
        • 36b42d36: Add a MCRIT plugin for Ghidra
      • oh-my-dump
        • ef5c3544: Merge pull request #5 from nevergiveupcpp/chore/codeowners
        • aa1ea5c9: chore: add code owners
        • 746e06bb: Merge pull request #4 from nevergiveupcpp/ci/node24-actions
        • ea489431: ci: update actions to node 24
        • c757dc98: Merge pull request #3 from nevergiveupcpp/build/multiplatform-support
        • 534968dd: chore: bump version to 1.0.17
        • 08426719: docs: update installation and configuration reference
        • 0404f7ac: build: add linux, macos and windows arm64 support
        • 42f38960: fix: resolve export filter type name collision
      • pyrrha
        • ca62056a: all: bump version
        • 938fbb59: fix(tests): fix export parameter in fs-cg
        • 1e196af4: fix: realign the backend-free test suite with dev
        • b9ee8715: tests: update decomp tests to check last features
        • f0ea1ce5: tests: update test_fw to test for inheritance mapping for cpp fw
        • 94fe53a4: mapper: remove thunk from decomp mapper and move imports into a dedic…
        • ec397228: mappers: remove cache system in intercg_mapper
        • 301bd45b: tests: update decomp tests to check last features
        • fa350f9d: mappers: do not decompile imported funcs
        • c3b93e3c: fix(main): options
        • 63c312fe: fix(cli): add missing debug flag
        • 158e80f3: cli: refactorize and improve documentation
        • 9ed490ec: fix(tests): adapt expected results to add new cpp binaries
        • d3f42a91: fix(tests): add new symlinks to expected results
        • 8032f12f: fix(ci): gitlab ci was not detecting correctly version given by a tag
        • 912f9c31: test(cli): cover C++ binaries in the fs-cg tests
        • df1f0eb2: fix(mappers): PLT stubs no longer shadow the functions they forward to
        • 79910ae4: feat(backend): expose thunk targets and import status
   2. 🔗 earendil-works/pi v1.4.0 release

      New Features

      • Image input for classifiers : codemode models.classify() accepts images for TypeSafe's Jev and Cloudflare's Clef models on typesafe, cloudflare-workers-ai, and OpenRouter. See Use classifier models and Codemode.
      • Models Configuration reference : every provider, model, model override, and compatibility field of models.json, generated from its schema. See Models Configuration.
      • Summaries without a fixed output cap : compaction and branch summaries use the model's output limit, so long reasoning no longer makes them fail. See Compaction.
      • Codemode waits for a free worker : parallel scripts and in-process subagents queue instead of failing, and PI_CODEMODE_MAX_WORKERS raises the limit. See Codemode limits.
      • Rex terminal support : OSC 8 hyperlinks, truecolor, and inline images.

      Added

      • Added a Models Configuration reference generated from the models.json schema, listing all provider, model, model override, and compatibility fields (#10790)
      • Codemode models.classify() now accepts images for TypeSafe's Jev and Cloudflare's Clef models on typesafe, cloudflare-workers-ai, and OpenRouter, and lists Clef Omni and Jev 1.14 on Workers AI.
      • Provider-level compat in models.json now also applies to classifier models, with the System One fields imageInput and sendImageOptInHeader for proxies that serve another service's classifiers. Extension classifier models accept compat too.
      • Added MiniMax-M3.1-Flash to the minimax and minimax-cn providers, with thinking levels low through max (#11121)
      • Added support for the Rex terminal: OSC 8 hyperlinks, truecolor, and inline images (#11131, #11150 by @petrroll, #11183 by @nihaals)

      Changed

      • Provider attribution headers now come from pi-ai's client identity. Extensions' before_provider_headers handlers no longer see the OpenRouter, NVIDIA NIM, and OpenCode attribution headers; returning null for one still removes it. Cloudflare requests send pi's detailed User-Agent instead of pi-coding-agent, as do GitHub release checks for tool downloads, and OpenCode requests send x-opencode-client whenever attribution is enabled, not only with a session.
      • generateSummary() and generateSummaryWithUsage() now ignore their reserveTokens parameter. Summary requests use the model's output limit instead.
      • Changed the default GitHub Copilot model from gpt-5.4, which Copilot retired, to gpt-6.1-sol.
      • Changed the default NVIDIA model to nvidia/nemotron-3.5-super-vl-120b-a12b (#10910 by @cv)
      • Changed the default Xiaomi model to mimo-v2.6-pro for the xiaomi and Xiaomi Token Plan providers, since mimo-v2.5-pro left the catalog.
      • Grok 4.3 and Grok 4.5 on the xai provider now offer the xhigh thinking level.
      • Sign in with ChatGPT: ChatGPT Business workspace usage-limit errors are not retried and tell the user to ask their workspace admin to increase the limit.

      Fixed

      • Fixed compaction and branch summaries failing with "generation hit the token cap" when reasoning used most of the fixed summary output limit. Summaries now use the model's output limit, and compaction.reserveTokens only controls when compaction starts (#9512, #9075).
      • Fixed models.schema.json missing descriptions for provider and model fields, so editors showed no hints for them (#10790)
      • Fixed pi update failing with "Managed install marker is missing or invalid" when managed-install.json starts with a UTF-8 BOM, which Windows PowerShell 5.1 adds when it rewrites the file.
      • Fixed HTML export showing literal asterisks for Markdown bold and italic next to CJK punctuation (#3353, #10154)
      • Fixed the terminal staying in mouse-tracking, focus-reporting, Kitty keyboard, and alternate-screen modes when pi exits without its normal terminal teardown, which flooded the shell prompt with escape sequences (#11170)
      • Fixed concurrent extension select/confirm/input/editor dialogs and inline custom() components in interactive mode: a second dialog replaced the first and the first promise never settled; closing the visible dialog now shows the previous one again (#11166, #9909)
      • Fixed pasting in the shell hanging after copying text in pi and suspending it with Ctrl+Z on Linux: the background wl-copy/xclip/xsel process that keeps serving the clipboard was suspended along with pi (#11179)
      • Fixed codemode scripts failing immediately when both codemode workers are busy, for example with parallel codemode calls or in-process subagents. Scripts now wait up to 60 seconds for a free worker, and PI_CODEMODE_MAX_WORKERS raises the limit of two workers (#11184)
      • Fixed extensions failing to load when importing @earendil-works/pi-ai/models (e.g. for clampThinkingLevel) by exposing the subpath through the extension loader aliases and virtual modules (#11156)
      • Fixed mcp.json files that start with a UTF-8 BOM failing to parse, which skipped all their MCP servers and made pi mcp add/pi mcp remove fail (#11191)
      • Fixed /compact <instructions> ignoring the instructions when summarizing the start of a turn that compaction splits. When the split turn was the only new content since the last compaction, the instructions were ignored entirely (#11058)
      • Fixed resumed sessions and /tree navigation leaving extension tools inactive when the branch recorded its tools before they were registered, such as tools from extensions installed after the session started. Extension tools the branch never added or removed are now active unless they are registered with defaultActive: false (#11062, #11075)
      • Fixed sessions breaking after recovery from a response cut off at the output limit: the truncated tool call was omitted but its tool results were kept, so providers rejected every later request (#11227, #11233 by @petrroll)
      • Fixed the grep tool following RIPGREP_CONFIG_PATH, where options such as --fixed-strings silently changed regex searches into literal ones. The tool now runs rg --no-config (#11203, #11230 by @petrroll)
      • Fixed Windows shell detection rejecting runnable Microsoft Store shell aliases (#9504 by @petrroll)
      • Fixed Windows shell detection missing PowerShell outside PATH and the legacy WSL bash.exe launcher when Windows is not installed in C:\Windows. pi now checks %ProgramFiles%\PowerShell\7, %SystemRoot%\System32\WindowsPowerShell\v1.0, and %SystemRoot% (#9501 by @petrroll)
      • Fixed GitHub Copilot sessions with large request bodies, such as many images, failing with HTTP 413 failed to parse request instead of compacting and retrying (#11016 by @petrroll)
      • Fixed the openai-codex provider offering gpt-5.5 and gpt-5.3-codex-spark, which always fail for ChatGPT accounts (#11173 by @lucasmeijer)
      • Fixed whitespace-only tool output (for example a bare \r\n from bash) making OpenAI Completions, OpenAI Responses, and Google requests fail with a 400 (#8720)
      • Fixed automatic retry not triggering for more gateway upstream failures, stream disconnected before completion errors relayed by Codex CLI proxies, and transient Google Vertex OAuth token refresh failures, and retrying errors because of digits inside request ids or byte counts (#10920, #11057, #10996)
      • Fixed OpenAI Responses models losing the prompt cache on every deferred tool load after a tool was removed (#10940)
      • Fixed Cloudflare Workers AI classifier pricing: Clef Flash costs $0.038 and Jev $0.042 per million input tokens instead of Jev being listed as free.
      • Fixed an unclosed $$ display-math block swallowing or corrupting every Markdown table after it (#11159)
      • Fixed Markdown bold and italic not rendering next to CJK punctuation (#10730 by @theBucky)
      • Fixed @ file autocomplete returning no results for queries containing regex metacharacters such as [ or ( (#10972)
   3. 🔗 Quarkslab's blog State of Post-Quantum Cryptography implementations rss

      Introduction

      One of the internship offers of the 2025-2026 season aimed to test Post- Quantum Cryptography (PQC) implementations with an internal differential fuzzing tool. As such, a list of targets had to be defined, and a state-of- the-art review of the featured PQC algorithms in popular open-source cryptographic libraries was done. Before presenting these implementations, let's first do a quick reminder on PQC.

      Post-Quantum Cryptography

      Cryptographic algorithms are based on problems that have historically been hard to solve with classical computers. However, among these problems, integer factorisation and the discrete logarithm problem can be solved efficiently by quantum computers, via Shor's algorithm. Although current quantum computers show progress, they are not yet capable of breaking the intended cryptographic algorithms. The main concern and motive for imminent replacement of quantum vulnerable algorithms is the "Harvest now, decrypt later" threat. An adversary can store sensitive data that was encrypted with quantum vulnerable algorithms, and decrypt it once quantum computers are able to.

      As a result, new cryptographic algorithms had to be designed, such that their security relies on problems that are not efficiently solvable by quantum algorithms. These new algorithms form what we call Post-Quantum Cryptography (PQC). In 2016, the US National Institute of Standards and Technology (NIST) launched a competition to standardize PQC algorithms, open to researchers from all over the world. They announced the first round of algorithms in 2022, with three signature schemes and one Key Encapsulation Mechanism (KEM). A new phase resulted in the selection of a second KEM, while an additional process to standardize more signature schemes continues.

      Post-Quantum migration timelines have been set by government agencies such as ANSSI and NSA. Major tech companies such as Google are planning for full post- quantum replacement as early as 2029. If you are interested in the PQC transition process, check out this blogpost by Angele Bossuat which explains Signal's PQC upgraded ratcheting mechanism.

      Post-Quantum algorithms

      To choose which algorithms to include for the fuzzing campaign, we focused on the ones standardized by NIST, as well as some others that were implemented for practical use.

      Key Encapsulation Mechanisms

      The Harvest now, Decrypt later threat specifically targets classical key exchange schemes. In consequence, PQC algorithms were designed for a cryptographic scheme called Key Encapsulation Mechanism (KEM). In this asymmetric scheme, Alice possesses a key pair and Bob wants to establish a shared secret with Alice. Bob uses Alice's public key to compute a ciphertext and a shared secret. This first step is called Encapsulation. Bob then sends Alice the ciphertext, and Alice performs the second step called Decapsulation. In this step Alice derives the shared secret from the ciphertext, using her private key.

      

      Diagram of a KEM from FIPS 203.

      The first KEM standardized by NIST is the Module-Lattice-Based Key- Encapsulation Mechanism (ML-KEM), specified in FIPS 2031. Its security relies on the Module Learning With Errors (MLWE) problem, a lattice-based problem with a particular polynomial ring setting. Its encryption and decryption mechanism is reminiscent of the ElGamal encryption scheme, utilizing randomness and replacing the discrete logarithm part with an MLWE instance.

      Since some of the post-quantum algorithms are relatively new, the possibility of discovering a way to classically break them is non-negligible. As a result, NIST decided to standardize a second KEM based on a different problem. This backup algorithm to ML-KEM is called Hamming Quasi-Cyclic (HQC)2. Its security relies on the Quasi-Cyclic Syndrome Decoding problem, based on error- correcting codes.

      There are other PQ KEM algorithms that were not standardized by NIST. Two of them are also lattice-based algorithms. The first one is FrodoKEM3. Its security is based on the standard Learning With Errors (LWE) problem. The main difference with ML-KEM is the absence of the polynomial ring structure. While the polynomial ring structure grants ML-KEM performance optimizations compared to standard LWE schemes, it also leverages additional hardness assumptions. This is the main motive behind the use of FrodoKEM, which is strongly considered by European government agencies.

      Part of the N-th degree Truncated polynomial Ring Units (NTRU) Prime project, Streamlined NTRU Prime (SNTRUP)4 is another lattice-based KEM. The NTRU Prime project aims to reduce the attack surface of NTRU lattice-based schemes by using a different polynomial ring structure.

      One more code-based algorithm was targeted, Classic McEliece5. It is the oldest code-based cryptosystem (1978). Its security relies on the standard Syndrome Decoding problem, which does not have a quasi-cyclic structure unlike HQC. It was not chosen by NIST for standardization due to its large public and private keys, leading to a costlier key generation, as explained in NIST IR 85456. However, it performs better for encapsulation and decapsulation. This can be advantageous in contexts where a single key pair is reused multiple times. Note however that due to recent advancement in its cryptanalysis, Germany's Office for Information Security (BSI) advises against using Classic McEliece.

      Another way to reduce the risk associated with the novelty of PQC algorithms and implementations is to use a hybrid scheme. This type of scheme combines a traditional and mature pre-quantum algorithm with a post-quantum one. It benefits from both the proven security of the former against classical attackers, and the conjectured security of the latter against quantum attackers. For example, in a KEM context, a shared secret key from each algorithm is generated. These two keys are then combined into one by using a Key Derivation Function (KDF). The security of a hybrid scheme also relies on the security of the hybridization technique used. Hybrid schemes are recommended by ANSSI for their PQC migration plan7. I chose to study the hybrid algorithm called X- Wing8. This algorithm combines the X25519 elliptic curve key exchange with ML-KEM, more precisely its ML-KEM-768 parameter set.

      Digital Signatures

      Module-Lattice-Based Digital Signature (ML-DSA), specified in FIPS 2049, was standardized by NIST along with ML-KEM. Its security also relies on the MLWE problem. Just like its KEM counterpart, its structure is similar to a previous discrete logarithm based scheme. Here ML-DSA is reminiscent of Schnorr signatures. They both follow the Fiat-Shamir paradigm, turning a zero-knowledge proof non- interactive by utilizing randomness and hash functions.

      Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA) was one of the three signature schemes selected at the third round of the NIST competition. It is based on the Gentry, Peikert, and Vaikuntanathan (GPV) framework10, instantiated over NTRU lattices and a new technique called Fast Fourier sampling. While the other selected algorithms have already been standardized, FN-DSA's standardization is still ongoing. As such, current implementations of the algorithm may not be compatible with the final standardized version. In consequence this algorithm was not targeted for the fuzzing campaign.

      Another set of post-quantum signature algorithms is what we call hash-based signatures. Their security relies on the one-way assumption of hash functions. They are what we call Few-Times Signatures schemes (FTS), meaning they have a limited amount of signatures possible. They use One-Time Signatures (OTS) and Merkle trees' structure to convert them into an FTS scheme.

      We distinguish two types of hash-based signature algorithms, the stateless ones and the stateful ones. Stateful algorithms require maintaining a state. They must keep track of which OTS key pairs have been used. This can be a drawback in specific contexts such as distributed systems. However, stateful algorithms tend to have better performance and signature sizes than stateless ones. In NIST SP 800-20811, NIST recommended the use of two stateful algorithms. Leighton-Micali Signature system (LMS), specified in RFC 855412, is the first one. It uses Leighton-Micali One-Time Signatures (LM-OTS), based on Winternitz OTS schemes. The other recommended stateful algorithm is the eXtended Merkle Signature Scheme (XMSS) specified in RFC 839113. Its main difference with LMS is the use of another Winternitz OTS variant called WOTS+, where bitmasks are used.

      The third signature algorithm selected in the competition, and later standardized by NIST, is Stateless Hash-Based Digital Signature Algorithm (SLH-DSA), specified in FIPS 20514. It is based on two other few-times signatures, FORS and XMSS. Its use of a very large number of FORS key pairs and a hypertree of XMSS Merkle trees allows it to have a stateless property.

      Implementations

      OpenSSL

      Founded in 1998, the OpenSSL project maintains a library that provides implementations of Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols, relying on their own implementations of cryptographic algorithms. It is most notably used by web servers for their secure HTTP connections. Written in C, OpenSSL has been forked to form other widely used open source cryptographic libraries. In 2025, they started featuring the following self-implemented Post-Quantum algorithms.

      • ML-KEM, standardized FIPS 203 version.
      • ML-DSA, standardized FIPS 204 version.
      • SLH-DSA, standardized FIPS 205 version.
      • LMS, standardized RFC 8554 version. Only the verification function is implemented. The author specifies that the stateful property is problematic for software implementations, and should rather be used for hardware ones.

      BoringSSL

      In 2014, Google decided to fork OpenSSL to build a cryptography library that specifically meets their needs. Before 2014, Google were using OpenSSL, but their accumulated number of patches in different copies of the library pushed them to create their own. BoringSSL is the current SSL library for Chrome, Android, and other apps and programs. BoringSSL announced their own post- quantum implementations when the first algorithms were standardized by NIST.

      • ML-KEM, standardized FIPS 203 version.
      • ML-DSA, standardized FIPS 204 version.
      • SLH-DSA, only two parameter sets out of twelve are available (SLH-DSA-SHA2-128s and SLH-DSA-SHAKE-256f). Other missing features from standardized version are internal vectors, pre-hash vectors, key generation from a seed, and deterministic signing.
      • X-Wing, version 02 of the RFC draft8.

      wolfSSL

      wolfSSL is a C library that implements SSL/TLS. It is designed for embedded systems which confers its portable, small, and fast attributes. Its cryptography is provided by the wolfCrypt library. Founded in 2004, it has been included in a variety of applications and devices such as smart automobile devices, mobile phones or credit card scanners. Their post-quantum support was originally based on the liboqs library. However, they replaced this integration with their own implementations, aiming for a reduction in code size and easier maintenance.

      • ML-KEM, standardized FIPS 203 version, along with x86_64 and ARM optimizations.
      • FrodoKEM, as specified in the draft15.
      • ML-DSA, standardized FIPS 204 version, along with x86_64 and ARM optimizations.
      • SLH-DSA, standardized FIPS 205 version.
      • LMS, standardized RFC 8554 version.
      • XMSS, standardized RFC 8391 version.

      liboqs

      liboqs is a collection of implementations of post-quantum algorithms written in C. It was created in 2018 as part of the Open Quantum Safe (OQS) project, which aims to support the PQC transition. It provides a common API for these algorithms as well as a test harness and benchmarking routines.

      • ML-KEM, standardized FIPS 203 version. Imported from PQ Code Package's mlkem-native implementation 16. Liboqs also features a GPU-optimized implementation from NVIDIA cuPQC17.
      • HQC, imported from the reference implementation18.
      • FrodoKEM, imported from PQCrypto-LWEKE, the reference implementation19.
      • Streamlined NTRU Prime, imported from the implementation used in OpenSSH20, itself based on the reference implementation21.
      • Classic McEliece, imported from the PQClean library22.
      • ML-DSA, standardized FIPS 204 version. Imported from PQ Code Package's mldsa-native implementation 23. Liboqs also features a GPU-optimized implementation from NVIDIA cuPQC17.
      • SLH-DSA, standardized FIPS 205 version. Imported from PQ Code Package's slhdsa-c implementation24.
      • LMS, imported from the RFC 8554 reference implementation25, by Cisco Systems.
      • XMSS, imported from the RFC 8391 reference implementation26.

      Libsodium

      Forked from the NaCl library in 2013 and maintained by Frank Denis, libsodium provides a wide range of cryptographic implementations. Written in C, its API prioritizes ease of integration. It is used in a wide variety of software, from communication platforms such as Discord or Wire, to cryptocurrencies like Zcash and text editors like Vim. Libsodium recently started featuring PQC in 2026 with the following algorithms:

      • ML-KEM, standardized FIPS 203 version, based on the reference implementation. Only the ML-KEM-768 parameter set is featured.
      • X-Wing, as specified in 8.

      AWS-LC

      AWS-LC is the general purpose cryptography library maintained and used by Amazon Web Services. It started around 2020 as a fork of BoringSSL. They announced fully deployed and production ready post-quantum implementations after NIST's first standardization process. PQC is notably integrated in their TLS implementation.

      • ML-KEM, standardized FIPS 203 version. Implementation imported from PQ Code Package's mlkem-native.
      • ML-DSA, standardized FIPS 204 version. Implementation imported from PQ Code Package's mldsa-native.

      OpenSSH

      Developed since 1999 by OpenBSD, OpenSSH is the most widely used tool for the SSH remote login protocol. It relies on various cryptographic algorithms implemented in their portable library written in C. OpenSSH features two hybrid key agreement protocols, each one combining an ECDH instance with respectively the following PQC algorithms:

      • ML-KEM, standardized FIPS 203 version. Implementation from Cryspen's Libcrux library written in Rust. The Rust code was translated to C using Eurydice, a Rust to C compiler. Only the ML-KEM-768 parameter set is featured.
      • SNTRUP, reference code is used. It is the same implementation liboqs currently uses.

      pqm4

      The pqm4 library is a benchmarking and testing framework that started in 2018 from the PQCRYPTO project, funded by the European Commission through the Horizon 2020 program. This library targets the ARM Cortex-M4 family of microcontrollers. It imports implementations from the PQClean library, but it also provides implementations with specific optimizations written in assembly for Cortex-M4. Here are listed the implementations that feature the M4 optimizations.

      • ML-KEM, standardized FIPS 203 version.
      • FrodoKEM, available in the Round3 release.
      • SNTRUP, available in the Round3 release.
      • ML-DSA, standardized FIPS 204 version.

      Nettle

      Nettle is a cryptographic library created in 2001 and developed by Niels Moller. It provides self-developed low level implementations of cryptographic algorithms, with a simple and general API to fit a variety of applications. Being a GNU package since 2009, it is used in several software such as GnuTLS. Since February 2026, Nettle features post-quantum cryptography with the following algorithm:

      • SLH-DSA, standardized FIPS 205 version.

      Lean Crypto

      Started in 2022 by Stephan Mueller, the leancrypto library exclusively provides self-developed PQC implementations in C. It targets constrained environments such as embedded systems, bare-metal environments, and Linux kernels. For example, the Shim bootloader, used by Linux, supports post- quantum cryptography for secure boot through LeanCrypto.

      • ML-KEM, standardized FIPS 203 version. Derived in parts from reference implementation.
      • HQC, derived in parts from PQClean's implementation.
      • ML-DSA, standardized FIPS 204 version. Derived in parts from reference implementation.
      • SLH-DSA, standardized FIPS 205 version. Derived in parts from reference implementation.

      Libgcrypt

      Libgcrypt is the cryptographic library provided for GnuPG, a PGP software. But its usage is independent of GnuPG. It was first released in 2001 and is written in C. It has featured post-quantum cryptography since 2024. Their post-quantum implementations derive from the reference implementations of each algorithm.

      • ML-KEM, standardized FIPS 203 version, based on reference implementation.
      • Classic McEliece, based on reference implementation.
      • Streamlined NTRU Prime, based on reference implementation.
      • ML-DSA, standardized FIPS 204 version, based on reference implementation.

      SymCrypt

      Started in 2006, SymCrypt is Microsoft's core cryptographic library, written in C. Originally intended for symmetric cryptographic operations, it has since 2015 been the primary cryptography library for all algorithms in Windows and other Microsoft products and services. In 2024 it started incorporating their own PQC implementations.

      • ML-KEM, standardized FIPS 203 version.
      • ML-DSA, standardized FIPS 204 version.
      • SLH-DSA, standardized FIPS 205 version. Code is not available in public git repository.
      • LMS, standardized RFC 8554 version.
      • XMSS, standardized RFC 8391 version.

      TrustCore SDK

      TrustCore SDK is a library that provides cross-platform security tools such as certificate-based authentication, encryption, and secure communications. Founded in the early 2000s, it was acquired in 2022 and made open-source by DigiCert, a certificate authority. Its usage targets IoT applications, embedded software, and safety-critical systems. TrustCore started integrating self-developed post-quantum implementations in 2025.

      • ML-KEM, standardized FIPS 203 version.
      • ML-DSA, standardized FIPS 204 version.
      • SLH-DSA, standardized FIPS 205 version.

      RustCrypto

      The RustCrypto project provides pure Rust implementations of cryptographic algorithms. It is widely used across Rust frameworks. For example, Rustls, the most popular Rust TLS implementation, features a RustCrypto provider. Though not yet audited, RustCrypto has various PQC implementations.

      • ML-KEM, standardized FIPS 203 version.
      • FrodoKEM, as specified in 27.
      • HQC, as specified in 2.
      • ML-DSA, standardized FIPS 204 version.
      • SLH-DSA, standardized FIPS 205 version.
      • LMS, standardized RFC 8554 version.
      • XMSS, standardized RFC 8391 version.
      • X-Wing, version 06 of the RFC draft8.

      Libcrux

      Libcrux is a cryptographic library developed in Rust by Cryspen (now pereq) since 2023. Many of their implementations use formally verified code from the HACL* project28. As for PQC, they entirely implement algorithms in Rust and formally verify their implementations with their tool called Hax29. Libcrux is most notably used by Signal for their Sparse Post-Quantum Ratchet (SPQR) protocol.

      • ML-KEM, standardized FIPS 203 version.
      • ML-DSA, standardized FIPS 204 version.
      • X-Wing, version 06 of the RFC draft8.

      Crypto (Go)

      The Go programming language includes a crypto package which contains self- developed cryptographic implementations in Go. Developed since the creation of Go in 2007 at Google, this standard library is used across many applications based in Go. It first introduced support for PQC in 2024.

      • ML-KEM, standardized FIPS 203 version.
      • ML-DSA, standardized FIPS 204 version. Internal implementation only.

      CIRCL

      First released in 2019, CIRCL is a collection of cryptographic primitives written in Go. Developed by Cloudflare, its goal is to experiment on the deployment of PQC and elliptic curve cryptography. It is used across Cloudflare's infrastructure. Their PQC implementations are independent of other Go cryptographic libraries.

      • ML-KEM, standardized FIPS 203 version.
      • FrodoKEM, heavily inspired from PQClean's implementation30. Only the parameter set FrodoKEM-640-SHAKE is featured.
      • ML-DSA, standardized FIPS 204 version.
      • SLH-DSA, standardized FIPS 205 version.
      • X-Wing, version 05 of the RFC draft8.

      Trail of Bits

      Trail of Bits is a cybersecurity research and consulting firm. Their cryptography team has implemented PQC algorithms in Go. These implementations are also self-audited by Trail of Bits, and aim for constant-time.

      • ML-DSA, standardized FIPS 204 version.
      • SLH-DSA, standardized FIPS 205 version.
      • LMS, standardized RFC 8554 version.

      Botan

      Botan is a C++ cryptography library that began in the early 2000s. Developed by Jack Lloyd and a community of contributors, it aims to be the best option for production cryptography. The German Federal Office for Information Security (BSI) has funded Botan for various projects, aiming to improve documentation, resilience, and features of the library. PQC features were added since 2023.

      • ML-KEM, standardized FIPS 203 version. Based on the reference implementation.
      • FrodoKEM, based on the reference implementation.
      • Classic McEliece, based on reference implementation.
      • ML-DSA, standardized FIPS 204 version. Based on the reference implementation.
      • SLH-DSA, standardized FIPS 205 version. Based on reference implementation.
      • LMS, standardized RFC 8554 version.
      • XMSS, standardized RFC 8391 version.

      Bouncy Castle

      Founded in 2000 in Australia, Bouncy Castle provides pure implementations in both Java and C# programming languages. Widely used for its Java and C# API, the Android operating system notably forked Bouncy Castle. Having experimented with PQC since 2013, algorithms were integrated after NIST standardization.

      • ML-KEM, standardized FIPS 203 version.
      • HQC, not featured in Bouncy Castle C#.
      • FrodoKEM, as specified in 3.
      • Streamlined NTRU Prime, as specified in 4.
      • Classic McEliece, as specified in specified in 5.
      • ML-DSA, standardized FIPS 204 version.
      • SLH-DSA, standardized FIPS 205 version.
      • LMS, standardized RFC 8554 version.
      • XMSS, standardized RFC 8391 version.
      • X-Wing, not featured in Bouncy Castle C#.

      corecrypto

      Developed and used by Apple, corecrypto is a library that provides self- developed implementations of cryptographic primitives. Formal verification is performed on their implementations through the use of the formal language Cryptol31 and formal verification tools Isabelle32 and Software Analysis Workbench (SAW)33. CoreCrypto notably features PQC that has been deployed in Apple's messaging app iMessage. - ML-KEM, standardized FIPS 203 version. - ML-DSA, standardized FIPS 204 version.

      Intel Cryptographic Primitives

      The Intel Cryptographic Primitives library offers self-developed cryptographic implementations that are optimized for different Intel CPUs and instruction set architectures. Post-Quantum algorithm started being featured in 2023.

      • ML-KEM, standardized FIPS 203 version.
      • ML-DSA, standardized FIPS 204 version.
      • LMS, standardized RFC 8554 version.
      • XMSS, standardized RFC 8391 version.

      Mbed TLS

      The Mbed TLS library provides implementations of cryptographic primitives, X.509 certificate handling as well as the SSL/TLS and DTLS protocols. It was specifically designed to be well suited for embedded systems. Post-Quantum cryptography is not yet fully supported as some algorithms are still in the library's road map. However, one specific PQC algorithm is already featured.

      • LMS, standardized RFC 8554 version. It is self-implemented and only features the LMS_SHA256_M32_H10 parameter set.

      Summary of libraries and implemented algorithms

      

      Non-exhaustive table of the feature PQC algorithms in open source libraries.

      Differential Fuzzing results

      The goal of the internship was to test the listed implementations to find vulnerabilities. There are several approaches to test cryptographic implementations. One is to use test vectors to compare operations results to defined standards. The open-source tool crypto- condor automatically performs compliance testing through test vectors. To learn more, you can refer to this blogpost by Julio Loayza Meneses.

      Another approach to test cryptographic implementations is through differential fuzzing, which was the approach used during the internship. To learn more on differential fuzzing and its applications in cryptography, you can refer to this blogpost by Celian Glenaz. Quarkslab has developed an internal closed-source differential fuzzer called DeltAFLy. It allows one to assess in- depth functional correctness (for edge cases not covered with test vectors), memory safety, and constant-time behavior of cryptographic implementations. DeltAFLy had already been used to test PQC implementations, you can find out more in this blogpost. Plenty of new PQC targets from the ones listed above remained to be tested with DeltAFLy.

      

      DeltAFLy's logo.

      ML-DSA and ML-KEM key checks

      The first implementation discrepancies I found were on the signature algorithm ML-DSA. OpenSSL rejects some private key inputs while liboqs accepts them and successfully returns corresponding signatures. These discrepancies come from additional private key checks that OpenSSL includes in its key parsing function. When an ML-DSA private key is parsed, the following parameters are decoded: (ρ,K,tr,s1,s2,t0)(\rho, K, \mathit{tr}, s_1, s_2, t_0). In particular, s1s_1 and s2s_2 are vectors of polynomials whose coefficients should be in a specific interval. For math enthusiasts, algebraically, s1∈Rq&ells_1 \in R_q^\ell and s2∈Rqks_2 \in R_q^k, with Rq=Zq[X]/(X256+1)R_q = \mathbb{Z}_q[X]/(X^{256}+1). When the fuzzer mutates valid inputs and gives a private key with out-of-range coefficients for the polynomials in s1s_1 or s2s_2, OpenSSL detects the malformation of the key and rejects the input. However, other libraries such as liboqs do not perform any key checks (see the next sub-section for a discussion on the consequences of this). Additionally, OpenSSL also recomputes the vector t0t_0 and the hash value tr\mathit{tr} from the decoded vectors s1s_1 and s2s_2. It then compares the recomputed values to the ones that were decoded.

      The specification of ML-DSA does not define any of these key checks, nor does it impose the requirement to check the validity of a key pair before use. As a result, libraries such as OpenSSL, BoringSSL, and SymCrypt choose to add the key checks described above, while others that thoroughly follow the specification do not.

      Similarly to ML-DSA, we found discrepancies related to key checks in ML-KEM. In this case, the key checks are defined in Section 7.1 of the specification1. Some of them are mandatory to perform before encapsulation and decapsulation, but one key check in particular is noted as optional. It is the pairwise consistency check (PCT). It consists in encapsulating with the public key, decapsulating the resulting ciphertext with the private key, and then verifying whether the two computed shared secrets correspond. Some libraries include this check in their key parsing function, while others do not. Consequently, the fuzzer generates inputs that do not pass the PCT, resulting in discrepancies.

      

      Diagram of a pair-wise consistency check.

      Another difference between some implementations arises from whether the mandatory key checks are performed in the encapsulation and decapsulation functions or in a separate, dedicated key check function. For example, libcrux's implementation of ML-KEM chooses the latter approach. The function validate_public_key(pk) performs the mandatory Encapsulation key check on the public key, defined in Section 7.2 of the specification. The function validate_private_key(sk, ct) performs the Decapsulation input check on the private key and the ciphertext, defined in Section 7.3 of the specification.

      Consequences of using malformed ML-KEM and ML-DSA key pairs

      If one were to use a corrupted ML-KEM key pair that is detectable by a PCT, the resulting shared secrets would differ, and symmetric encryption would fail. For ML-DSA, regarding out-of-range s1s_1 and s2s_2 coefficients, the specification states the following: "This can be a concern when running SimpleBitUnpack and BitUnpack on inputs that may come from an untrusted source."9. However, these specific concerns are not mentioned again nor explained further in detail in the specification.

      The secret vector s1s_1 is used in the computation of the challenge-response:

      z=y+c⋅s1z = y + c \cdot s_1 with c∈Rqc \in R_q the public challenge, y∈Rq&elly \in R_q^\ell the private nonce, and z∈Rq&ellz \in R_q^\ell. To avoid a bias towards s1s_1 in the response zz, the coefficients of s1s_1 must fall within the relatively short range [−η,η][-\eta, \eta], and zz is accepted and returned only if its polynomial coefficients fall inside the range:

      W1=[−γ1+β+1, γ1−β−1]W_1 = [-\gamma_1 + \beta + 1,\ \gamma_1 - \beta - 1] with γ1\gamma_1 and β\beta depending on the parameter set. This process is called rejection sampling and makes the returned zz independent of s1s_1 if the latter has in-range coefficients. Similarly, the following value is biased towards the secret vector s2s_2:

      r=w−c⋅s2r = w - c \cdot s_2 with w∈Rqkw \in R_q^k the commit of yy sent by the signer along with the signature. During signing, another rejection sampling is applied to rr. Its values are to be accepted only if its polynomial coefficients fall inside the range W2=[−γ2+β+1, γ2−β−1]W_2 = [-\gamma_2 + \beta + 1,\ \gamma_2 - \beta - 1] with again γ2\gamma_2 and β\beta depending on the parameter set.

      ML-DSA's key generation ensures that the coefficients of s1s_1 and s2s_2 fall inside the required range. However, the private key's encoded format allows for coefficients of s1s_1 and s2s_2 to be outside of the required range if the right bits are flipped. In such cases, some values in the acceptance ranges W1W_1 and W2W_2 can never be reached by respectively zz and rr. As a result, the accepted zz and rr are no longer independent of s1s_1 and s2s_2, which leaks secret information and compromises the security of the algorithm. Moreover, there exists a fault injection attack34 that specifically targets the coefficients of s1s_1, underlining why these coefficients must be in range. A reporting of missing ML-KEM and ML-DSA key checks in liboqs can be found here.

      

      Summary table of the key checks included in the tested libraries.

      XMSS OID parsing bug in RustCrypto

      Another discrepancy found was in the implementation of XMSS in RustCrypto. This discrepancy is caused by an actual implementation bug. Some parameter sets of XMSS use a hypertree of XMSS Merkle trees to achieve a larger amount of signatures possible. These specific parameter sets are called Multi-Tree XMSS (XMSSMT). The first four bytes of an XMSS/XMSSMT public key correspond to a parameter set identifier that the specification calls the OID. XMSS and XMSSMT's OIDs are defined separately, meaning they both start from zero and hence have colliding OIDs.

      RustCrypto's implementation distinguishes XMSS and XMSSMT's OIDs by adding an offset to XMSSMT's OIDs, in the definition of an enum defined as XmssOid. When verifying signatures using a public key imported as raw bytes, the public key has to be parsed into the library's VerifyingKey<P> type, with P specifying the parameter set used. This is done by using the method VerifyingKey::<P>::try_from(bytes). This method begins by calling the function parse_oid_and_params(bytes), which parses the XmssOid from the first four bytes of the imported public key.

      /// Parses the OID and initializes params from the first bytes of a key.
      /// Tries XMSS OIDs first, then falls back to XMSSMT.
      fn parse_oid_and_params(bytes: &[u8]) -> XmssResult<(XmssOid, XmssParams)> {
          if bytes.len() < XMSS_OID_LEN {
              return Err(Error::InvalidOid(0));
          }
          let mut raw_oid: u32 = 0;
          for i in 0..XMSS_OID_LEN {
              raw_oid |= (bytes[XMSS_OID_LEN - i - 1] as u32) << (i * 8);
          }
          let oid = XmssOid::try_from(raw_oid).or_else(|_| XmssOid::from_xmssmt_raw_oid(raw_oid))?;
          let mut params = XmssParams::default();
          oid.initialize(&mut params)?;
          Ok((oid, params))
      }
      

      In the above code snippet, we can see that parse_oid_and_params(bytes) first attempts to parse the OID as an XMSS one, by directly calling the method XmssOid::try_from(value). If this first call fails, it will fall back to XmssOid::from_xmssmt_raw_oid(oid) which attempts to parse the OID as an XMSSMT one. This method will add the XMSSMT OID offset before calling XmssOid::try_from(value) again.

      The problem arises when importing an XMSSMT public key whose OID collides with an XMSS one. Since parse_oid_and_params(bytes) attempts to parse the OID as an XMSS one first, it will wrongly return the XmssOid of the colliding XMSS parameter set, instead of the actual XMSSMT one with the added offset. As a result, when VerifyingKey::<P>::try_from(bytes) later compares the parsed OID to the expected one that P specifies, as shown in the code snippet below, the check will wrongly fail.

      impl<P: XmssParameter> TryFrom<&[u8]> for VerifyingKey&lt;P&gt; {
          type Error = Error;
      
          fn try_from(value: &[u8]) -> Result<Self, Self::Error> {
              let (oid, params) = parse_oid_and_params(value)?;
              let expected_oid = P::oid();
              if oid != expected_oid {
                  return Err(Error::InvalidOid(oid.raw_oid()));
              }
      ...
      

      XMSSMT parameter sets that have an OID that collides with an XMSS one cannot be used if the public key is imported.

      The library's tests only include one XMSSMT parameter set. It has a colliding OID but the test uses a public key generated from the library's key generation function, and not a raw bytes one that has to be parsed. The reporting of this bug can be found here.

      Conclusion

      With recent PQC migration timelines set by state agencies and major tech companies, open source cryptographic libraries are progressively including PQC algorithms. With more and more implementations being developed, making sure that they can safely be deployed for practical usage is a big part of the post-quantum transition process.

      In this blog post, we listed and documented the featured PQC algorithms in some of the most widely used open-source cryptographic libraries. We also showed that our tool DeltAFLy is capable of finding bugs and implementation discrepancies.

      While implementation bugs arise from mistakes that must be corrected, implementation discrepancies often come from a permissive algorithm specification. In the latter case, the implementation discrepancy is a distinct choice from the library, which often comes down to good practices like in the case of the ML-DSA and ML-KEM key checks.

      Acknowledgements

      I want to personally thank Julio Loayza Meneses for supervising my internship, Celian Glenaz for helping me understand and use his tool DeltAFLy, and Quarkslab for the great experience and opportunity I had.

      ---

      1. NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard &larrhk&larrhk

      2. Hamming Quasi-Cyclic (HQC) specification &larrhk&larrhk

      3. FrodoKEM: Learning With Errors Key Encapsulation, Algorithm Specifications And Supporting Documentation &larrhk&larrhk

      4. NTRU Prime: round 3 submission &larrhk&larrhk

      5. Classic McEliece: conservative code-based cryptography, cryptosystem specification &larrhk&larrhk

      6. Status Report on the Fourth Round of the NIST Post-Quantum Cryptography Standardization Process &larrhk

      7. Avis de l'ANSSI sur la migration vers la cryptographie post-quantique &larrhk

      8. X-Wing: General-Purpose Hybrid Post-Quantum KEM &larrhk&larrhk&larrhk&larrhk&larrhk&larrhk

      9. NIST FIPS 204: Module-Lattice-Based Digital Signature Standard &larrhk&larrhk

      10. Trapdoors for Hard Lattices and New Cryptographic Constructions &larrhk

      11. Recommendation for Stateful Hash-Based Signature Schemes &larrhk

      12. RFC 8554: Leighton-Micali Hash-Based Signatures &larrhk

      13. RFC 8391: XMSS, eXtended Merkle Signature Scheme &larrhk

      14. NIST FIPS 205: Stateless Hash-Based Digital Signature Standard &larrhk

      15. FrodoKEM: Key Encapsulation from Learning with Errors , version 03 &larrhk

      16. Pq-Code-Package/Mlkem-Native &larrhk

      17. NVIDIA cuPQC &larrhk&larrhk

      18. HQC reference implementation &larrhk

      19. PQCrypto-LWEKE: FrodoKEM implementation &larrhk

      20. Openssh-Portable/Sntrup761.c &larrhk

      21. NTRU Prime: Software &larrhk

      22. PQClean implementation of Classic McEliece &larrhk

      23. Pq-Code-Package/Mldsa-Native &larrhk

      24. Pq-Code-Package/Slhdsa-c &larrhk

      25. Cisco/Hash-Sigs : LMS reference implementation &larrhk

      26. XMSS reference implementation &larrhk

      27. FrodoKEM, ISO standard &larrhk

      28. HACL*: A High-Assurance Cryptographic Library &larrhk

      29. hax: A high assurance translations tool &larrhk

      30. PQClean implementation of FrodoKEM &larrhk

      31. Cryptol: The Language of Cryptography &larrhk

      32. Isabelle: a generic proof assistant &larrhk

      33. SAW: The Software Analysis Workbench &larrhk

      34. Correction Fault Attacks on Randomized CRYSTALS-Dilithium &larrhk

   4. 🔗 @HexRaysSA@infosec.exchange 🍎 IDA 9.5 brings better DriverKit support for reversing Apple drivers: mastodon

      🍎 IDA 9.5 brings better DriverKit support for reversing Apple drivers:
      • Types for every DriverKit SDK from 19 to 25
      • Classes, layouts and vtables recovered, including private-framework classes
      • Kernel calls named, even in stripped drivers and arm64 kernelcaches

      👉 https://hex-rays.com/blog/ida-9.5-apple-driverkit-shared- cache

   5. 🔗 Hex-Rays Blog IDA 9.5: Apple DriverKit Shared Cache rss

      

      IDA 9.5: Reversing Apple DriverKit Drivers

      Apple is moving third-party drivers out of the kernel and into DriverKit. A DriverKit driver, or dext , is the kernel's C++ driver framework, IOKit, compiled into a user-space library. It is still built from C++ classes with virtual methods, and it gets work done by sending the kernel messages.

      

   6. 🔗 HexRaysSA/plugin-repository commits sync repo: +2 releases rss

      sync repo: +2 releases
      
      ## New releases
      - [IDA-MCP-Hub](https://github.com/captain-ai-hub/ida-mcp): 0.9.8
      - [oh-my-dump](https://github.com/nevergiveupcpp/oh-my-dump): 1.0.17
      

   7. 🔗 r/Harrogate Thinking about going out this weekend rss

      Newish to the area, trying to expand my circle a bit. Thought going a few bars might meet some people.

      Any recommendations where to go?

      submitted by /u/Apprehensive_Ring666
      [link] [comments]

   8. 🔗 smol-machines/smolvm smolvm v1.31.1 release

      What's Changed

      • chore(nix): bump flake to 1.31.0 by @github-actions[bot] in #1917
      • Never lower a branch source's memory ceiling below what its cgroup still holds by @BinSquare in #1921

      New Contributors

      • @github-actions[bot] made their first contribution in #1917

      Full Changelog : v1.31.0...v1.31.1

   9. 🔗 smol-machines/smolvm smolvm v1.31.0 release

      What's Changed

      • Improve Linux checkpoint extraction with sequential read advice by @BinSquare in #1852
      • Let a paused machine's export and resume read the same artifact by @BinSquare in #1854
      • Prepare SmolVM v1.30.2 for release by @BinSquare in #1855
      • Overlap a cache disk publish's sync with its hash and upload, and report the sync's progress by @BinSquare in #1856
      • Keep a checkpoint's resolver options on restore and let machine update set them by @BinSquare in #1857
      • Keep image pull progress flowing while one large layer downloads by @BinSquare in #1859
      • Bring PTY streamed exec to parity with framed, non-blocking pipe exec by @Vishv07 in #1825
      • Give uploads without an explicit owner to the workload container's user by @BinSquare in #1862
      • Harden virtio devices against out-of-range guest input by @BinSquare in #1865
      • Keep an image's symlinked resolv.conf and hosts instead of writing through them by @BinSquare in #1863
      • Remove the retired guest DNS proxy and stop starting its host listener by @BinSquare in #1866
      • Size /dev/shm like a VM, add --shm-size, and raise inotify limits by @BinSquare in #1864
      • Say the guest agent is outdated when it rejects a request it does not know by @BABTUNA in #1214
      • feat(cli): support credential set-header (#1860) by @azrod in #1861
      • Add --deny-cidr as deny egress rules by @BABTUNA in #1212
      • Document shipped features that had no docs by @BinSquare in #1878
      • Read secrets from the host keychain with --secret-keychain by @BinSquare in #1876
      • Hash cache bases with ring instead of sha2 by @BinSquare in #1883
      • Accept file uploads up to 1 GiB when the Content-Length is declared by @BinSquare in #1882
      • Record stratum handshakes and match TLS server names against the egress watchlist by @BinSquare in #1885
      • Fail a fork whose clone exited right after boot instead of reporting it running by @BinSquare in #1872
      • List the Go SDK in the README's embeddable install commands. by @BinSquare in #1891
      • Wait for a branch source's checkpoint in proportion to its RAM, and answer a timeout with a retryable 503 by @BinSquare in #1892
      • Size the shared extraction cache under the shared lock so a trim no longer stalls branches for seconds by @BinSquare in #1899
      • Serialize preparing a chunked checkpoint for restore so overlapping restores of one fresh checkpoint stop deleting each other's half-built tree by @BinSquare in #1900
      • Make the shared machine JSON builder public by @BinSquare in #1893
      • Say a start may be in progress when exec finds no agent by @BinSquare in #1894
      • Document that registry images boot without network by @BinSquare in #1895
      • Check for the agent rootfs before compiling, and build bundles nightly by @BinSquare in #1896
      • Add a --state-dir flag on Linux by @BinSquare in #1897
      • Report the branch memory reserve and per-child overhead in /capacity by @BinSquare in #1898
      • Pin libkrun at the vsock muxer guard fix and rebuild every bundled libkrun by @BinSquare in #1901
      • Update rustls-webpki and webpki-roots past the distrusted emSign roots by @BinSquare in #1902
      • Mount the agent's root overlay with index=off so a restart cannot lose hardlinked files by @BinSquare in #1890
      • Replace a dangling resolv.conf link instead of failing every exec after systemd-resolved is installed by @BinSquare in #1889
      • Keep a large file write's finalize from timing out the host by @BinSquare in #1881
      • Keep supplementary groups on exec, let uploads set owner and mode, add --no-wait-ready to batch branches by @BinSquare in #1904
      • Handle branch children outgrowing the host's RAM: OOM victim order and a memory pressure guard by @BinSquare in #1905
      • Pin libkrun at the macOS chmod, AMD CPUID and host-full errno fixes by @BinSquare in #1907
      • Sum node memory for /capacity from per-process counters instead of smaps_rollup so a node with many machines answers in milliseconds and stops self-cordoning by @BinSquare in #1908
      • Remove the timing-dependent agent keepalive test by @BinSquare in #1909
      • fork control socket: retry a read interrupted by a signal by @BinSquare in #1914
      • pack: the default cache cap never exceeds the filesystem that holds it by @BinSquare in #1910
      • storage test: read the ext4 superblock magic instead of shelling out to file by @BinSquare in #1911
      • agent: a missing target is NOT_FOUND even when the read-path resolver canonicalizes it by @BinSquare in #1912
      • client test: give the partial-frame shutdown test scheduling slack by @BinSquare in #1913
      • ci: build the release profile with thin LTO and 16 codegen units by @BinSquare in #1915

      New Contributors

      • @azrod made their first contribution in #1861

      Full Changelog : v1.30.1...v1.31.0

   10. 🔗 backnotprop/plannotator v0.28.25 release

       Follow @plannotator on X for updates

       Missed recent releases? Release | Highlights
       ---|---
       v0.28.24 | A new look for the Inbox, Send now, tag agents, comment on an agent's message, much smaller reads for agents, links in HTML pages
       v0.28.23 | Inbox replies reach sessions with background subagents, dictated text no longer goes missing, 👍 Looks good reaches the agent, notifications that never fail silently
       v0.28.22 | 👍 Looks good, full view for files, one viewer for a thread's images and files, every session prints its URL, PLANNOTATOR_BROWSER=none opens nothing
       v0.28.21 | Message an agent from the Inbox, video attachments, Open in for attachments, Code / Tests / Generated in code review, writes from other websites refused
       v0.28.20 | Inbox search (⌘K), real folder names for projects, data files open in the code view, word-only replies leave questions open
       v0.28.19 | Ask this session in T3 Code, folder sessions load shared stylesheets and images, the agent note asked once per agent, Copy connect prompt
       v0.28.18 | plannotator inbox connects your agents, agents are told when to use the Inbox, rendered Markdown in code review, Inbox Settings in sections
       v0.28.17 | The Inbox on iPads and narrow windows, the reply bar no longer cuts off "Keep open", a Pi crash on /reload fixed
       v0.28.16 | The Inbox on a phone, a doorbell for new questions, Mark read, step through a thread's files, replies when the asking session ended
       v0.28.15 | Long Inbox threads fold to what is new, "Skipped N questions" replies, Inbox list and sidebar fixes
       v0.28.14 | Agents can replace an earlier question, comment on a guided review in the Inbox, issue numbers link to the repository
       v0.28.12 | Update notices and plannotator update, attach any file to an Inbox message, questions with context, links to attached files

       What's New in v0.28.25

       A follow-up to 0.28.24 for the Plannotator Inbox: Re-ask, delivery ticks on the list, a count of new messages on the tab, a right-click menu on threads, and click Inbox to refresh. All PRs by @backnotprop.

       Plannotator Inbox

       Re-ask open questions

       When two or more questions in a thread are still open, Re-ask sits beside Reply. It asks the agent to ask them again together in one new message, with fresh context. Picks you made but didn't send go along as answers.

       • #2018

       Delivery ticks on the list

       A small mark before a row's time shows where your last reply is: a clock while it's queued, dots while it's sending, ✓ when it's saved for an agent, ✓✓ once it's delivered.

       • #2016

       A count of new messages on the tab

       The tab reads "(3) Plannotator Inbox" and its icon gets a red badge while threads hold agent messages you haven't looked at.

       • #2011

       Right-click a thread

       Right-click a row (or Shift+F10) to copy its link or thread ID, mark it read or archive it.

       • #2024

       Click Inbox to refresh

       Click Inbox, the project you're on or the list's title to load the list again, as a page reload would. The icon turns to ↻ on hover. Nothing is marked read.

       • #2027

       Smaller changes

       • Close or swipe away a toast with its × or a sideways drag. #2021
       • Images in What's new. The page shows the images a release carries, saved on your computer first. #2017
       • Older Claude Code sessions update with/reload-plugins, without restarting. #2009
       • Long lists stay fast. Rows off screen are skipped, and only changed rows redraw. #2022
       • Shift-click works on attached HTML pages , joining several elements to one comment. #2019
       • The Sent toast fits on one line. #2010
       • A linked page's Back button gets focus reliably. #2015
       • A row no longer shows "Sending" while the agent is working after a turn ended and started again within a second. #2030

       Plannotator

       Smaller changes

       • Comments wrap long words and links , show the year on older dates, keep the time visible, and show right-to-left names correctly. Question context keeps its line breaks. #2020
       • Documents open faster : the annotation toolbar no longer forces a layout pass when a document opens. #2025

       Install / Update

       macOS / Linux:

       curl -fsSL https://plannotator.ai/install.sh | bash
       

       Windows:

       irm https://plannotator.ai/install.ps1 | iex
       

       Claude Code Plugin: The plugin and the plannotator binary update separately, so run the install script above as well. In a terminal:

       claude plugin marketplace update plannotator
       claude plugin update plannotator@plannotator
       

       Then restart Claude Code. Inside Claude Code, run /plugin marketplace update plannotator, then open /plugin → Installed → plannotator → Update now.

       Pi:

       pi update --extensions
       

       OpenCode: Re-run the install script above. It now also clears the OpenCode 2 plugin cache.

       What's Changed

       • Inbox: update older Claude Code sessions with /reload-plugins by @backnotprop in #2009
       • Inbox: the Sent toast fits on one line by @backnotprop in #2010
       • Inbox: a count of new messages on the tab by @backnotprop in #2011
       • e2e: tag in a file comment measures the passage once the pane stops moving by @backnotprop in #2012
       • e2e: wait for the touch-opened composer to take focus before Escape by @backnotprop in #2013
       • Inbox: a linked page's Back takes focus once it is drawn by @backnotprop in #2015
       • Inbox: delivery ticks on list rows by @backnotprop in #2016
       • Inbox: images in What's new by @backnotprop in #2017
       • Inbox: Re-ask open questions by @backnotprop in #2018
       • Inbox: shift-click joins more elements to one comment on an attached HTML page by @backnotprop in #2019
       • @plannotator/ui: five display fixes from Workspaces' break-ui pass by @backnotprop in #2020
       • Inbox: close or swipe away a toast by @backnotprop in #2021
       • Inbox: skip layout for rows off screen by @backnotprop in #2022
       • Inbox: right-click a thread row to copy its link by @backnotprop in #2024
       • @plannotator/ui 0.53.1: two fewer forced layouts on document open by @backnotprop in #2025
       • Inbox: click Inbox to refresh the list by @backnotprop in #2027
       • Inbox: tell the windows when a turn ends and starts again between delivery looks by @backnotprop in #2030
       • Tests: two DOM tests that failed at random in CI by @backnotprop in #2031

       Community

       Every PR in this release is by @backnotprop.

       Full Changelog : v0.28.24...v0.28.25

3. October 20, 2026
   1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-10-20 rss

      IDA Plugin Updates on 2026-10-20

      New Releases:

      • chernobog v6.5.0
      • diaphora Diaphora 3.4.4

      Activity:

      • augur
        • 103e7868: docs: update
      • chernobog
        • e96039ef: docs: add Chernobog 6.5.0 release notes and update README
        • bad5076c: fix: reduce constant-masked selectors before Legacy MBA SMT search
        • 8acf0c1a: fix: canonicalize verified complements in MBA SMT proof expressions
        • 2a2f6055: fix: prioritize complete linear word regions in Legacy MBA SMT
        • 98793b69: fix: reserve 750 ms ctree budget for Legacy MBA SMT chains
        • e5900be5: fix: execute unconditional MBA SMT chains without invariant inference
        • d2401dd0: feat: promote CoBRA to default MBA SMT backend
        • 0e83dbb9: fix: retain 500 ms site cap for all unmasked Legacy MBA SMT expressions
        • 83d35afd: ci: add configurable native parallelism input for MBA CoBRA runtime w…
        • cf61d8a3: fix: preserve 250 ms site cap for masked and small Legacy MBA SMT exp…
        • 76018126: fix: prepare MBA SMT word proofs for constant queries and retain per …
        • 68f9dfda: fix: skip MBA SMT invariant inference for empty unconditional CFG wra…
        • e74216d0: fix: prepare cached word proofs before Legacy MBA SMT search
      • diaphora
        • 14ce7dae: Merge pull request #391 from joxeankoret/joxeankoret-patch-18
        • c04ab4fc: Update README.md
        • 7bf142b3: Merge pull request #390 from joxeankoret/joxeankoret-patch-17
        • a0946609: Update ida-plugin.json
      • ffxiv_bossmod
        • 21555358: oh yeah
      • haruspex
        • 390c9e5e: docs: update
      • rhabdomancer
        • 51b5167f: docs: update
      • XrefsExt
        • f1e57756: plugins
   2. 🔗 19h/chernobog v6.5.0 release

      Chernobog 6.5.0

      Changes in v6.4.0...v6.5.0.
      The README retains the cumulative changes since 6.2.0.

      • CoBRA is the default MBA candidate generator — algebraic simplification
        now uses CoBRA in builds that include it. Independent Z3 checks still prove
        the proposed value and the actual emitted microcode or ctree expression before
        replacement. CHERNOBOG_MBA_BACKEND=legacy selects the previous generator;
        builds with CHERNOBOG_WITH_COBRA=OFF retain Legacy. An exhausted or failed
        CoBRA invocation does not silently restart candidate search with Legacy.
        See CoBRA integration and limits.

      • Flag-field and mask simplification — known-bit analysis tracks constant
        shifts, extensions, extraction, and multiplication by powers of two. It
        combines nested masks, removes masks from unobserved bits, and changes XOR
        to OR only when the possible set bits are disjoint. Plain field-store values
        can reuse eligible scalar locals without changing their destination or
        surrounding memory operations. Volatile and unresolved memory operands remain
        excluded from the ordinary-memory semantic model. See the
        mask-normalization examples.

      • More complete caller and loop constants — the calls-stage pass can prove
        contextual constants after Hex-Rays narrows return values, including across
        propagatable ordinary copies marked DONT_COMB. It preserves those original
        instructions and does not rewrite protected copies. This additional pass runs
        only for reachable CFG cycles. If a proved proposal cannot be lowered, analysis
        continues to other sites in the same immutable snapshot instead of discarding
        all remaining opportunities.

      • Complete-word reconstruction and reusable proofs — both generators try
        complete unmasked linear word regions up to 32 bits before their prefixes,
        including beneath typed truncations and extensions. Universally proved word
        identities are reused within the same solver session for caller, candidate,
        and emitted-value queries. A bounded proof-only normalization gives equivalent
        complemented words a common arithmetic form. Candidates retain their original
        typed semantics and still require both value proofs.

      • Legacy masked-selector reduction — fixed conjunctive and disjunctive
        constant-mask selectors can reduce to masked XOR expressions before general
        reconstruction. Complementary masks can reduce to one XOR; partial masks retain
        their fixed output bits. Each template is proved before substitution, with
        signed promotions and narrow return conversions preserved.

      • Analysis time reserved for final scalar recovery — validated unconditional
        chains execute directly through their assignments and stores, avoiding invariant
        inference where there is no branch or cycle. Qualifying Legacy functions reserve
        750 ms of the normal allowance for ctree recovery; masked Legacy sites retain
        their 250 ms cap. The shared per-function allowances remain 1 s for normal
        analysis and 30 s for Deep, with individual solver queries capped at 250 ms.
        These allowances do not bound total decompiler runtime. See the
        backend scheduling and budget details.

      • Proofs bound to the actual replacement — emitted-object receipts retain
        the exact SDK expression that was independently checked. Before applying a
        replacement, the plugin rechecks its source, destination, types, frame, effects,
        and current analysis domain. Post-proof edits, stale snapshots, cancellation,
        and ineligible deadlines reject the replacement; CoBRA proposals cannot use
        the existing preverified Legacy fallback's deadline exception. Structural
        cleanup also advances the mutation epoch so earlier receipts cannot authorize
        later edits.

      • Backend and rejection diagnostics — chernobog_mba_smt_stats(ea) reports
        the selected backend, candidate and emitted-proof outcomes, application and
        rejection counts, phase timings, and deadline overshoot. Invalid backend
        overrides and explicitly requested unavailable CoBRA builds have distinct
        diagnostics. Proof counters describe attempts; applied records actual
        rewrites.

   3. 🔗 @binaryninja@infosec.exchange For the stable-branch-enjoyers, there's a fresh Krypton (6.0) R2 release mastodon

      For the stable-branch-enjoyers, there's a fresh Krypton (6.0) R2 release available where you regularly download all your fine Binary Ninja releases:

      https://binary.ninja/2026/10/20/6.0-release-2.html

   4. 🔗 Simon Willison Battle Drones - a vibe coded RTS with audio-based multiplayer rss

      My latest vibe coded game experiment is a Command & Conquer style RTS (Real Time Strategy) game called Battle Drones (play it here). Unlike my previous experiments, this one is actually fun to play. I'm somewhat embarrassed to admit that I got there by telling Claude to "Make it a LOT more fun". It also supports multiplayer between nearby devices using audio to synchronize game state! Here's what I've built so far, and some of the things I learned along the way.

      • Battle Drones
      • How I built this
      • v1: the initial prototype
      • v2: full sprites
      • v3: varied terrain
      • v4: the fun update
      • v5: Battle Drones goes 3D
      • v8: Archipelago
      • v10: Goliath, and agent battles
      • Agent battles
      • v11: Random Maps
      • v12: Multiplayer via sound
      • Some thoughts
      • Update: Online multiplayer support

      Battle Drones

      My initial goal was to build an RTS game I could play on my phone, in the style of Command & Conquer. I have fond memories of the 1995 original (I liked Red Alert too) and wanted to recapture a little bit of the magic.

      After 12 major iterations (and 321 commits by coding agents, mainly Claude Code) I now have a browser-based game that works on mobile and desktop, has multiple play modes, several maps (including a random map generator) and even supports multiplayer for two devices within microphone range of each other. (Update: also online multiplayer; the audio multiplayer induced headaches!)

      Here's a video demo of Battle Drones running in a desktop browser:

      Features so far include:

      • 9 buildings, 7 ground vehicles, 6 aerial vehicles, 3 infantry units - all 3D models, which you can browse here
      • Fog of war
      • Different weapons are needed to target aerial or ground vehicles
      • Six maps, across five biomes - temperate, desert, arctic, volcanic, tropical
      • A random map generator
      • Skirmish mode - red vs. blue on a rotationally symmetrical map
      • Last Stand mode - one player holds out against as many waves of enemies as possible
      • Area effect weapons: Barrage, EMP, Drop Pod, Sky Hammer
      • Crate drops with bonus resources
      • In-game music that responds to events - it gets more intense as fighting breaks out
      • Different in-game AI personalities (Balanced, Rush, Air Swarm, Boom, Skyforce, Ironclad)
      • AI vs. AI mode, to watch those personalities play each other
      • The Goliath - a giant stomping mech with laser eyes and arm cannons and the ability to establish a new base
      • Mutators that add extra rules or twists
      • A "Daily Op" challenge
      • Ranks and achievements (Medals)
      • Agent vs. Agent mode where two LLMs can play Battle Drones against each other
      • A multiplayer mode based on two nearby phones communicating via audio messages, an extension of my earlier experiment with Chirp Pong

      How I built this

      Battle Drones is heavily vibe coded - I've reviewed almost none of the code, and it's built in a language (TypeScript) that I've hardly used myself. I've playtested it quite a bit though, and it's been through a large number of iterations since I started the project.

      Here's a rough history of the project so far, including key prompts and links to transcripts.

      v1: the initial prototype

      I started out with Claude Fable 5 back in July:

      We are going to build a mobile friendly RTS game - command and conquer style - called Battle Drones, in which two armies of drones (both flying and ground-based) battle for territory and resources

      Let's start with a MVP design, ask me some questions

      Here's a shared transcript. I'd given Claude Code for Web an environment variable with an OpenAI API key and told it to use the OpenAI Image Generation API for assets, which got me some basic sprites.

      You can try v1 here - it looked like this:

      

      It's recognizable as an RTS, has building mechanics and the ability to select and direct units, and a basic AI to play against.

      This first version was barely a proof of concept, and it wasn't any fun to play.

      Claude used the Phaser 2D game framework for these early versions. I didn't even realize this until several iterations later!

      v2: full sprites

      The second version (try v2 here) added sprites for all of the vehicles and the "AI vs. AI" mode, so I could watch the game playing without having to directly control it myself.

      Claude proved reasonably competent at prompting OpenAI's image models to generate sprites. You can browse the v2 sprites in the public/assets/sprites folder.

      

      v3: varied terrain

      It still wasn't much fun, and the graphics were boring. It was now October, and I had upgraded to Claude Opus 5.5. I told it:

      Massively improve this game. Make the graphics and gameplay better (keep it mobile friendly). Render new graphics using the latest OpenAI GPT image API (lookup details) with the API key in the environment variable. Add new unit types and balance the gameplay better. Also add new buildings and better, more varied terrain.

      This resulted in five new maps with generated background tiles in a variety of styles, visible here. Opus also regenerated the sprites, making them much more visually appealing. You can try v3 here - it looks like this:

      

      This is starting to feel like a real game! It still wasn't very fun to play though - I found myself getting bored pretty quickly.

      v4: the fun update

      So far my Battle Drones experiment was confirming my previous belief that coding agents can build a thing that looks like a game but can't actually make something that's genuinely compelling to play.

      I shared this theory with someone over dinner, and then thought to myself that I should give the models a proper chance to prove me wrong. I prompted Opus 5.5 on my phone:

      This game isn't fun enough yet. Make it a LOT more fun.

      This time I was running in Ultracode mode, where Claude Code (in this case Claude Code for Web) runs "dynamic workflows", described in their docs as:

      A dynamic workflow is a JavaScript script that orchestrates many subagents at once.

      This kicked off many hours of work. I started it in the evening and didn't get a playable result back until late into the next morning. But the results were spectacular.

      You can try v4 here - it looks like this:

      

      I had Claude write its own release notes - here are the highlights:

      Every skirmish and Daily Op now opens with a choice, gives the side that's losing a way back, and pulls the armies into the middle of the map. There are also two new ways to play.

      • Openers: pick Blitz, Industry or Air Wing before the clock starts.
      • Call-down powers: Barrage, EMP, Drop Pod and the Sky Hammer orbital strike.
      • Objectives and salvage: Uplink relays, supply drops and wrecks worth scrap.
      • Feel: combat juice, adaptive music, unit voices and an announcer.
      • Command: battle alerts, game speed, saved squads and touch placement.
      • New modes: Last Stand survival waves and an 8-mission Ops campaign.
      • Progression: heroes, an after-action report with awards, a career, 7 mutators and a Daily Op.

      Fights run longer and swing more. In 1,200 AI-vs-AI test matches on Normal, games still undecided after 25 minutes fell from 14% to 0.9%. The share of wins by a side that had been 800+ scrap behind rose from 24% to 46%.

      Part of the reason Claude took so long was that it ran over a thousand simulated playtest sessions, and used the results to rebalance the existing units, add new ones, and introduce new features.

      v5: Battle Drones goes 3D

      After the success of Ultracode at "Make it a LOT more fun", I decided to be more ambitious:

      Port this game to three.js with 3D models for all of the buildings and vehicles and landscapes

      That was another overnight run. I woke up to this v5 version:

      

      The new 3D models were entirely constructed by Claude in TypeScript code.

      v6 (play v6 here) added some more visual polish. v7 (play v7) added robot infantry (troopers, rocket squads, snipers) and a "Condor" troop carrying aircraft.

      v8: Archipelago

      I was beginning to feel guilty at how little actual design input I had into the game - it really had been a case of me saying "make it more fun" and "add visual polish" for the past few releases.

      I'd noticed that the AI didn't use the new infantry and troop carrying aircraft from v7 very often - there wasn't a great strategic reason to use them.

      It would be neat if we had a new map with a new game mechanic that actively encouraged players to load up Condors with infantry robots and send them out into the map.

      This resulted in my longest prompt yet:

      Design a new map. Goal is to make different strategic incentives that encourage use of Infantry and Condors and aerial vehicles.

      To do this the map will have limited harvester resources but several more uplinks - but uplinks will be on islands that are inaccessible by land vehicles or infantry. These uplinks can also not be claimed using air vehicles. The ONLY way to get them is to fly infantry there in a Condor.

      Armies always start with a Condor and a single squad. If an army has no Condor a new one will be provided for free, flying in from the edge closest to their HQ and landing there. That free condor will come with a single free squad on board.

      The two HQs should be entirely separated by water, but still accessible by vehicles thanks to two bridges across the map in different places

      I want to encourage a battle over uplinks.

      The map should be the times the size of other maps - still square

      First research and then critique this design. Only build after we have agreed on any modifications

      You get to design a new biome for this

      The result was the tropical Archipelago map, with seven island uplinks that players can only capture by flying out infantry in a Condor. It's definitely the most fun map to play, once you've got the hang of the basic game mechanics from the simpler maps. The v9 edition made that map a little more interesting - it now looks like this:

      

      v10: Goliath, and agent battles

      I decided to add giant robot mechs to the game - think Jaegers from Pacific Rim, or Titans from Warhammer 40,000.

      Here are some of the prompts I used to brainstorm with Claude:

      Help me brainstorm ideas for adding giant robots to this game - think dreadnoughts or titans from W20K - how could we do this in a way that enhanced gameplay, kept things balanced, added unique twist? Don't overthink this yet

      Let's keep brainstorming. I like the idea that it's a mobile base - that can accept harvested scrap and can have buildings built near it (even if it later moves on) and can produce infantry units too. An interaction with condor would be neat but I don't know what that could be.

      Idea: as it gets damage it loses the ability to fire some weapons - by default it has eye laser (like lancers) and arm canons (like titan) and two shoulder mounted mortars, plus machine guns similar to a squad of troops

      Damage knocks out mortars and then laser - it always has guns. You can't build next to a building that was only put there because of the mech, you need the mech there for off-base building and only within three squares of it

      [...] Lets do two condors can carry the mech

      The end result is really cool.

      Goliaths can be constructed using a Gantry - a building that can only be created after first building a Fab, Bay, Airpad, and Tech Lab. You can see the Goliath under construction, and it then walks out from the Gantry and can march around the map.

      Goliaths can "anchor", which digs them into the ground. In their anchored state they can act as a new HQ, constructing infantry units and additional buildings in a new area.

      Two Condor aircraft can hook onto a Goliath, at which point it can be flown around the map!

      The game now ends when you destroy the enemy's HQ building and any Goliaths they might have built.

      There are also a couple of mutators relating to Goliaths:

      • Goliath Armada starts each side with four airborne Goliaths (each with a pair of Condors) and no other units.
      • Robot Love adds a special rule: if enemy Goliaths get close to each other on the battlefield they fall in love and the game ends in a draw. (Thank Natalie for that one).

      Agent battles

      The other v10 feature is agent battles. In musing about how multiplayer could work I had an idea: what if different LLMs could fight it out in the game?

      Fun extra challenge: think about how we might make multiplayer available to coding agents. It would be neat if we could set up a battle between eg GPT-6 Sol and Claude Opus 5.5 where each model has access to a tool which gives them information about the game (presumably non-visual, but only the information they could see through fog of war etc) and lets them control their units etc [...]

      Consult ~/dev/llm/docs and include notes in that file about how LLM could be used here via a new tools plugin

      Opus 5.5 went to work on this, producing this AGENT-BATTLES.md proposal and then implementing and testing it. The feature also includes the ability to record and replay these battles - here's a replay of Claude Haiku 5.5 vs. GPT-6 Luna, and here's that same battle in a separate debug tool that shows the underlying prompt responses.

      

      The prompt that drives agent battles can be seen here.

      There are a few more replays like this linked in the README. I hope to turn this into a full league table at some point in the future.

      v11: Random Maps

      This version exists purely because I glanced at my Claude Usage page one day and saw that I'd only used 75% of my weekly allowance and it was resetting in 45 minutes. I decided to see if I could get an extra Battle Drones feature from my remaining tokens, and picked "random map" as the target:

      Design and implement a mechanism for generating a random map using any of the available biomes - it should be the size of the largest map and rivers and bridges and rocks and forest and scrap and crystals are all in play. Make them rotationally symmetric and use a seed to allow them to be selected or reused later. You have 45 minutes to build this! Be creative.

      Here's the transcript, and an image Claude generated to show me its work:

      

      v12: Multiplayer via sound

      I only just got this working, so I've not had much time to actively test it yet. The latest Battle Drones now supports multiplayer via two devices sat within microphone distance of each other!

      This feature started out as my Chirp Pong experiment from last week. I pointed Claude Code at that working proof of concept:

      Clone Simonw/tools from GitHub and look at recent branches for the example pong game that uses web microphone to implement multiplayer between two phones via audio signals

      Build a version of that for battledrones

      Opus built this Radio Probe tool to measure how much bandwidth we could get between two devices and, based on positive results from that, implemented a full audio modem system. I've tried it between laptops, iPhones and iPads so far and it seems to work really well!

      Why use sound for this? Because I love static HTML that costs nothing to run, and I don't want to spin up a server somewhere and then stay responsible for keeping it operating for as long as anyone might want to play the game.

      Some thoughts

      I know almost nothing about game development. This makes it a great opportunity to try out coding agents in a field where my existing software engineering experience has less impact on the results.

      Games are also super low stakes. The worst that can happen is one of my silly game experiments suffers a bug.

      This morning (via Hacker News) I found Steam Fans Are Begging for a No-AI Filter as Steam Next Fest Is Filled With Slop. I wouldn't personally dream of submitting Battle Drones to an event like this - it's still way too low effort to warrant consideration as a legitimate indie gaming project.

      ... but I can now see a path to vibe coded games like this being taken seriously. Battle Drones is fun, it looks good, it has innovative features (the multiplayer-over-audio thing is a first for an RTS as far as I can tell).

      I'd love to see what someone with better taste than me and a driving passion to produce something truly exceptional could build!

      A few other observations from this project:

      • Static HTML and JavaScript is a fantastic medium for games development. WebGL works great, and Three.js (and Phaser before it) are excellent platforms to build on that the current models know inside out.
      • This also lets them run as Progressive Web Apps - I didn't ask for it, but Battle Drones works offline. I was able to play it on a plane despite never having directly installed it - my phone had it cached.
      • Giving Claude an OpenAI API key and telling it to generate images using OpenAI's models works really well. It can view the images it has generated and iterate on the prompts.
      • Opus 5.5 is spectacular at 3D modeling using Three.js (and Blender, and no doubt other 3D applications as well). The same is true of GPT-6 Astra. They are absolutely capable of building models for 3D game projects.
      • For features like replay and multiplayer it's useful to have a deterministic simulation engine. At one point Claude had to replace calls to Math.sin() and Math.cos() and friends with custom versions because different browsers (Chrome vs. Safari, for example) returned very slightly different numbers, desynchronizing the replay.
      • Opus 5.5 can write music! There are no audio files in this project - the soundtrack is entirely generated through code, varies across different maps, and even gets more intense as the battle heats up. See Scrimshaw Jukebox for a previous experiment with Claude for music composition.
      • I still can't get over how well the prompt "Make it a LOT more fun" worked.
      • Tools are effectively free. I prompted up the Radio Probe, the Model browser, the Agent vs. Agent debug tool, and Claude Code built a bunch of tools for itself that I haven't even explored myself.
      • Audio-based multiplayer between static HTML games works! I hope to see a whole lot more games use this same pattern - in digging around today I've not found much prior art beyond Siner by Alon Horesh and ggwave by Georgi Gerganov (also of llama.cpp fame).
      • Claude Code "Ultracode" burns tokens like there's no tomorrow, but it can also solve complex problems (like adding audio-based multiplayer) from a single prompt.
      • I'm still not quite over the guilt of building software in this way. I don't feel like I've earned the right to create something this good, in a field in which I have so little prior experience! At this point I've shown it to enough people in private that it felt wrong not to publish it for everyone else to see and learn from.

      Update: Online multiplayer support

      Earlier in this article I said:

      Games are also super low stakes. The worst that can happen is one of my silly game experiments suffers a bug.

      Then I tried playing the multiplayer version with Natalie... and the high pitched modem sounds gave her a nasty headache!

      That's a pretty bad bug. I added a warning and was then inspired to build proper network multiplayer. I tried getting WebRTC to work but couldn't get a connection going between two of my own devices even on my own WiFi network, so I had Claude build a simple, stateless WebSockets relay server instead:

      If I wanted to support multiplayer between two devices at a very low cost without storing any state on the server could I do that with a tiny asyncio web server running on the cheapest Fly instance?

      Build the server and the fly.toml for deploying it, use Fly application name battledrones-relay - put that in a folder in the repo, include deploy instructions in the README in that folder

      Here's the resulting server. Since this scales to zero and runs on a single Fly.io shared-cpu-1x instance it should cost me no more than $2.19/month - and that's if it stays hot and serving connections the whole time.

      Battle Drones now supports online multiplayer. Click "Duel a friend online", then either share the resulting room URL via your messaging app of choice or have them snap a picture of the displayed QR Code.

      I also added a feature where you can copy JSON of the match once it has ended and then feed that into the replay feature to rewatch your game.

      I didn't expect to introduce online multiplayer this soon, but the headache bug felt like it warranted an urgent alternative.

      You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options.

   5. 🔗 backnotprop/plannotator v0.28.24 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.28.23 | Inbox replies reach sessions with background subagents, dictated text no longer goes missing, 👍 Looks good reaches the agent, notifications that never fail silently
      v0.28.22 | 👍 Looks good, full view for files, one viewer for a thread's images and files, every session prints its URL, PLANNOTATOR_BROWSER=none opens nothing
      v0.28.21 | Message an agent from the Inbox, video attachments, Open in for attachments, Code / Tests / Generated in code review, writes from other websites refused
      v0.28.20 | Inbox search (⌘K), real folder names for projects, data files open in the code view, word-only replies leave questions open
      v0.28.19 | Ask this session in T3 Code, folder sessions load shared stylesheets and images, the agent note asked once per agent, Copy connect prompt
      v0.28.18 | plannotator inbox connects your agents, agents are told when to use the Inbox, rendered Markdown in code review, Inbox Settings in sections
      v0.28.17 | The Inbox on iPads and narrow windows, the reply bar no longer cuts off "Keep open", a Pi crash on /reload fixed
      v0.28.16 | The Inbox on a phone, a doorbell for new questions, Mark read, step through a thread's files, replies when the asking session ended
      v0.28.15 | Long Inbox threads fold to what is new, "Skipped N questions" replies, Inbox list and sidebar fixes
      v0.28.14 | Agents can replace an earlier question, comment on a guided review in the Inbox, issue numbers link to the repository
      v0.28.12 | Update notices and plannotator update, attach any file to an Inbox message, questions with context, links to attached files

      What's New in v0.28.24

      A big Inbox release: a new look, Send now, tagging agents, comments on an agent's own words, and much smaller reads for agents. Links inside HTML pages now work everywhere you annotate. 23 PRs, all by @backnotprop.

      Plannotator Inbox

      A new look

      The Inbox has a softer, calmer design, with tooltips that match the app instead of the browser's. A new text size setting (Settings → General, 12 to 15) makes everything larger or smaller at once.

      • #1971, #1977, #1982, #1990

      Send now

      After you send a reply, the line under it says whether it is queued (the agent is busy and gets it when its turn ends) or on its way. Send now puts it into the agent's running turn right away, on Claude Code, Pi and OpenCode 2.

      • #1968

      Tag agents

      Type @ in a reply or a comment to choose which agents get it.

      • #2005

      Comment on an agent's message

      Select any words in an agent's message and comment on them, the same way you comment on an attached file. Your comments go with your next reply.

      • #1997

      Agents read much less

      When an agent reads a long thread, it now gets the newest messages in full and older ones as one line each, with the option to open any of them. A 46-message thread went from about 48,000 tokens to about 7,000. Agents can also search the Inbox.

      • #1999, #2002

      Knowing when to update Claude Code sessions

      When a Claude Code session still runs an older Plannotator plugin than the one installed, the Inbox says so and shows how to load the new one.

      • #2001, #2008

      One full-screen mode for files

      Every kind of attached file opens full screen the same way.

      • #1958

      Removed: the Decisions page. The Inbox no longer has a Decisions page, and agents no longer have the tools that recorded decisions.

      Smaller changes

      • The skill picker in New message opens right under the line you are typing instead of behind the footer (#2004)
      • New message is in the list header while the sidebar is closed (#1987)
      • The toast sits at the bottom of the window and its words are never cut off (#1988)
      • The notification line above the list reads more cleanly (#1989)
      • Rows that Show brings in stay highlighted a little longer (#2003)

      Plannotator

      Links in HTML pages work

      In HTML you annotate, and in HTML pages attached in the Inbox, a click on a link now follows it and ⌘-click (Ctrl-click) pins it for a comment. On a phone, a tap follows and a press-and-hold comments. Live apps follow the same rule.

      • #2000

      Smaller changes

      • Docs: WSL2 needs no remote mode, so Ask this session stays on (#1984); the guide skill is now called guided-review, with a new guided-plan skill (#1996); the @plannotator/ui handoff docs are up to date (#1986)

      Install / Update

      macOS / Linux:

      curl -fsSL https://plannotator.ai/install.sh | bash
      

      Windows:

      irm https://plannotator.ai/install.ps1 | iex
      

      Claude Code Plugin: The plugin and the plannotator binary update separately, so run the install script above as well. In a terminal:

      claude plugin marketplace update plannotator
      claude plugin update plannotator@plannotator
      

      Then restart Claude Code. Inside Claude Code, run /plugin marketplace update plannotator, then open /plugin → Installed → plannotator → Update now.

      Pi:

      pi update --extensions
      

      OpenCode: Re-run the install script above. It now also clears the OpenCode 2 plugin cache.

      What's Changed

      • Inbox: one full-screen mode for files by @backnotprop in #1958
      • Inbox: say a sent reply is queued, and Send now delivers it into the running turn by @backnotprop in #1968
      • Inbox Soft (1/4): Soft on theme tokens by @backnotprop in #1971
      • Inbox Soft (4/4): buttons, dialogs, Settings and a file's chrome painted Soft by @backnotprop in #1977
      • Inbox: component tooltips everywhere, no native titles by @backnotprop in #1982
      • Docs: WSL2 needs no remote mode, so Ask this session stays on by @backnotprop in #1984
      • Inbox: remove Decisions by @backnotprop in #1985
      • Docs: packages/ui HANDOFF.md and README.md match core 0.25.13 / ui 0.53.0 by @backnotprop in #1986
      • Inbox: New message in the list header while the sidebar is closed by @backnotprop in #1987
      • Inbox: the toast sits at the bottom of the window, and its words show whole by @backnotprop in #1988
      • Inbox: the notification line above the list reads cleanly by @backnotprop in #1989
      • Inbox: a text size setting (12–15, default 14) by @backnotprop in #1990
      • Docs: the guide skill is now guided-review; add guided-plan by @backnotprop in #1996
      • Inbox: comment on the text of an agent's message by @backnotprop in #1997
      • Inbox MCP: smaller results by @backnotprop in #1999
      • Inbox: links inside an attached HTML page open by @backnotprop in #2000
      • Inbox: say when an agent session needs a restart after an update by @backnotprop in #2001
      • Inbox MCP: windowed thread reads, text transcripts, and agent search by @backnotprop in #2002
      • Inbox: rows that Show brings in stay lit longer by @backnotprop in #2003
      • Inbox: the skill picker in New message opens at the cursor by @backnotprop in #2004
      • Inbox: tag agents in a reply or a comment by @backnotprop in #2005
      • Inbox: the restart note leads with /exit and the resume command by @backnotprop in #2008

      Community

      Every PR in this release is by @backnotprop.

      • @balaji-dutt reported that Ask this session was off under WSL2 even though the review page was only reachable on the same machine (#1983), which led to the WSL2 docs fix.

      Full Changelog : v0.28.23...v0.28.24

   6. 🔗 exe.dev The Topology of an LLM Agent Loop With Tool Use rss

      When I look at a new agent, I break it down by focusing on its topology. An agent is three things:

      1. A model. Your model choice defines the agent’s “smarts,” i.e., which tasks it can accomplish.
      2. The agentic loop (see: The Unreasonable Effectiveness of an LLM Agent Loop with Tool). Loop choice determines UX.
      3. The set of tools. This defines the capabilities and power (and blast radius) an agent has.

      (2) and (3) together are often called “the harness.”

      

      All of this is code, and code has to run somewhere. Where these run—the topology of these agents —has implications on cost, capability, effectiveness, and security for companies building AI products and people using AI tools.

      Example 1: Claude Code

      Claude Code on your laptop uses Anthropic’s hosted model, runs the agentic loop on your laptop, and runs the tools also on your laptop.

      

      Example 2: ChatGPT

      ChatGPT uses OpenAI’s hosted model, runs the agentic loop on their backend server, and runs tools also on their backend servers.

      

      Example 3: Siri on your Mac

      Siri on your Mac uses a mix of models: smaller ones run on your Mac, and bigger ones run in Apple’s Private Cloud Compute. The agentic loop runs on your Mac, and so do the tools, like the one that reads your Messages.

      

      Example 4: Amp Orbs

      Amp Orbs use models from Anthropic, OpenAI, and others, run the agentic loop in Amp’s backend, and run the tools in your Orb, a VM that Amp creates for each thread with your code on it.

      

      Example 5: Shelley on exe.dev

      If you’re using our Shelley coding agent on an exe.dev VM, the model is hosted, and the agent and the tools run on the VM.

      

      In all of these cases, remote MCP servers can expose tools running elsewhere.

      Where Is the Model?

      Your choices here are GPUs hosted by someone else or your own GPUs.

      As the controversy around the Navier-Stokes equation reminds us, the only way to be confident nobody is training on your data is to not send your data to them. If you’re working on common problems, it probably doesn’t matter. But I suspect a hapax legomenon could end up in the training data somewhere.

      If I want to, say, use some LLMs to OCR and classify some scanned bills on my computer, I’m reaching for local models, because speed doesn’t matter (it can run overnight), and privacy is guaranteed. (Shout out to the Apple Vision Framework, by the way. And ScanShelf is an example where I do this!)

      Ken Thompson’s 1984 Turing Award lecture, Reflections on Trusting Trust, hits different now. That paper poses how a Trojan Horse could be hidden in a compiler, invisible in the compiler’s source code, as it’s propagated by the compiler. The LLM (a compiler? maybe? no?) could have some tampered weights that lead the agent to do something naughty; it’s been tried. We must choose which vendors to trust.

      LLMs are wreaking havoc on traditional SaaS cost structures as well. If you have, for example, a diagram-drawing SaaS, and you want to let your users use agents to edit the diagrams: who’s paying for the tokens? Before agents, your costs were a few database rows per customer; now that customer can rack up a $100 bill with a few sentences. At exe.dev, our users can bring their own ChatGPT subscriptions to build applications with OpenAI models. This is a win- win. I expect we’ll see more “bring your own model” options.

      This is my bespoke drawing editor, with a built-in agent. You’re going to see “agent drawers” in every product.

      Where is the loop?

      If you’re using, say, ChatGPT, the loop is running in OpenAI’s servers. If you’re running a coding agent, the loop is running on your laptop. The loop could run in a web browser (e.g., as I did in ItsyBitsy, and as many others have as well).

      I have found over and over again that I find other people’s loops limiting. For example, I much prefer pointing my preferred agent at my source code and my observability tooling rather than using the observability vendor’s agent loop.

      The loop has to maintain the message history (since an LLM agent is operating on the entire history), and that has to be stored somewhere. Storing it in SQLite for Shelley remains a decision I’m very happy with. Pi Durable also offers SQLite.

      

      The loop also provides the UI for the agent. Can it display images? Are there customizations to give feedback on video? Is it limited to plain text? Can it handle attachments? Can a conversation be shared? All of these are choices the loop must make.

      Where are the Tools?

      Agents aren’t agents without tools. The jump from one “completion” from an LLM to an agentic loop is transformational. If an agent can empirically test the thing it’s writing, the results are better.

      The problem with executing code is that, well, you have to do it somewhere, and you have to assume that the code being executed is unpleasant and will steal all the cookies from your pantry and set off the fire alarms at night unnecessarily (or worse).

      The code execution isn’t lightweight: it’s not all editing files; compilation, video processing, running tests… the workload can be heavy.

      Virtual Machines are the gold standard for executing code safely. Even with VMs, there are tons of variables: can it talk to the network? Does it have credentials to talk to other services? Is there enough memory?

      Running coding agents locally works too, but the blast radius for the “Lethal Trifecta” is bigger. Exposure to untrusted content could lead the agent to leak secrets, for example.

      You can build many useful agents without a full machine. Pyodide, a Python running in WASM, is sandboxable without a full machine. Likewise, there are several WASM JS implementations. You can always run the agent loop on the browser, too, which runs sandboxed code day in and out. (See https://blog.philz.dev/blog/sandboxes/ for a short list of some of these approaches.) You can also give an agent the ability to run SQL on a readonly database connection, and that’s pretty safe!

      Note that the tools don’t have to be in the same address space as the loop; they don’t even need to be in the same neighborhood. When you’re using a “Connector” in ChatGPT (roughly their word for MCP), you’re giving the agent loop (which is hosted by OpenAI) access to resources somewhere else. Concretely, if you use the exe.dev MCP, your ChatGPT can operate on your exe VMs. When you’re talking about MCP, map out where the OAuth tokens are held.

      To make their products useful, Muse, GrokBot, OpenAI Dots, and so on are all providing VMs.

      Mapping Agents

      There are tradeoffs everywhere you look. Framed as topology, you can break down any agentic product. Once you know what’s running where, you can reason about what a product can and cannot do.

      In my work at exe.dev, I use five independent agentic loop implementations nearly every day. (Our coding agent, Shelley; our alert agent, Sisyphus; our deployment supervisor, Athena; an ops agent, Puck; our repo news Slack agent.) Shelley is a general purpose coding agent, but the other four are bespoke software. More and more software will ship with agentic loops built-in.

      I also constantly interact with other systems, and use agents to glue them together. The companies that get it make their product legible to coding agents. I can just smell Clayton Christensen's Innovator's Dilemma as I switch from better, more polished, established products to ones that let me point an agent at them. Of the nine points in Revisiting Joel’s Test, this is the most important one.

      There is no “one loop to rule them all.” Good UX (and a good set of tools) for a general-purpose chatbot is not the same as good UX for a coding agent.

      I leave you with the most useful code of the year. When you insert agents into your products, think of the topology of those agents.

      def loop(llm):
          msgs, msg = [], user_input()
          while True:
              msgs += [msg]
              output, tool_calls = llm(msgs)
              print("Agent: ", output)
              if tool_calls:
                  msg = [ handle_tool_call(tc) for tc in tool_calls ]
              else:
                  msg = user_input()
      

   7. 🔗 r/Harrogate ThoughtBubble Accommodation? rss

      Hello everyone, hope this is allowed!
      I plan to attend thoughtbubble this year, and on submitting my pages for the sample script they put out this year.
      However I’ve been so far unable to find accommodation in Harrogate that won’t near-break me financially :) so I’m just chancing my arm here, does anyone know of a place to look in the town that might be more budget-friendly or even if there was a spare floor going for a day or so? Any suggestions are much appreciated :)

      I’ll be in Harrogate from the evening of the 13th to the morning of the 16th.

      Thanks in advance :)

      submitted by /u/Defina8ly_not_takken
      [link] [comments]

   8. 🔗 Rust Blog Announcing rustup 1.29.2 rss

      The rustup team is happy to announce the release of rustup version 1.29.2.

      Rustup is the recommended tool to install Rust, a programming language that empowers everyone to build reliable and efficient software.

      What's new in rustup 1.29.2

      This is a small release which only updates the rustls-webpki and webpki-root- certs dependencies to address the problematic eMudhra intermediate certificates issue described in CVE-2026-111943.

      See also RUSTSEC-2026-0382.

      Further details are available in the changelog!

      How to update

      If you have a previous version of rustup installed, getting the new one is as easy as stopping any programs which may be using rustup (e.g. closing your IDE) and running:

      $ rustup self update
      

      Rustup will also automatically update itself at the end of a normal toolchain update:

      $ rustup update
      

      If you don't have it already, you can get rustup from the appropriate page on our website.

      Rustup's documentation is also available in the rustup book.

      Caveats

      Rustup releases can come with problems not caused by rustup itself but just due to having a new release.

      In particular, anti-malware scanners might block rustup or stop it from creating or copying files, especially when installing rust-docs which contains many small files.

      Issues like this should be automatically resolved in a few weeks when the anti-malware scanners are updated to be aware of the new rustup release.

      Thanks

      Thanks again to all the contributors who made this rustup release possible!

   9. 🔗 Filip Filmar Bazelizing Third-Party FPGA Designs: Two Case Studies rss

      Converting existing open-source FPGA projects to Bazel and rules_openxc7 makes hardware builds reproducible, eliminates machine-specific paths, and enables one-command bitstream generation without vendor licensing hurdles. This article examines two real conversions of external repositories: mmRISC-2, a silicon-proven RISC-V SoC with heavy SystemVerilog hierarchies, and Custom RISC CPU with Systolic Matrix Accelerator, a pipelined processor paired with a 2D systolic array coprocessor. Both examples illustrate how Bazel transforms fragile build scripts into reliable, sandboxed workflows.

4. October 19, 2026
   1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-10-19 rss

      IDA Plugin Updates on 2026-10-19

      New Releases:

      • oh-my-dump Oh My Dump v1.0.16 for IDA Pro 9.x

      Activity:

      • oh-my-dump
        • ee60b0dd: ci: parameterize builds and bundle release assets
        • f57347cd: ci: attach standalone DLL to releases
        • 0af0b1c0: ci: preserve release title format
        • ef591292: build: update IDA SDK library lookup
        • c0209d05: ci: build on pushes and PRs, publish releases on tags
        • 5bf11189: chore: update plugin metadata and bump version to 1.0.16
   2. 🔗 Quarkslab's blog MbedTLS Security Audit rss

      Introduction

      Mbed TLS is a widely deployed open-source TLS, DTLS, and X.509 library maintained by Trusted Firmware, targeting constrained and embedded environments. It is used as the cryptographic backbone of products across the IoT, automotive, and industrial sectors, and forms the TLS layer for projects such as the Trusted Firmware family.

      Version 4.0 represents the most significant architectural change in the project's history. The cryptographic layer has been extracted into a standalone library, TF-PSA-Crypto, which implements the PSA Cryptography API v1.2 as specified by Arm. The Mbed TLS repository now consumes TF-PSA-Crypto as a submodule, and the configuration space has been split across two header files: mbedtls_config.h for the TLS and X.509 options, and psa/crypto_config.h for the cryptographic primitives. All RNG callbacks have been removed in favor of a mandatory call to psa_crypto_init() before any operation.

      The Open Source Technology Improvement Fund (OSTIF) commissioned Quarkslab to perform a security audit of this new architecture.

      Scope

      The primary objectives of this audit are:

      • Architectural transition review. Assess the security implications of the Mbed TLS 3.x to 4.0 split, focusing on the trust boundary between the TLS layer and TF-PSA-Crypto, the correctness of the PSA API integration, and whether the removal of the legacy crypto paths introduces new attack surface.

      • PSA API usage correctness. Verify that key attributes (usage flags, permitted algorithms, lifetimes) are correctly set and enforced throughout the TLS and X.509 code paths, and that the mandatory psa_crypto_init() dependency is properly documented and enforced.

      • Memory safety. Identify memory corruption vulnerabilities in the SSL/DTLS context management (in particular, session serialization and resumption), the X.509 parsing subsystem, and the PSA key store.

      • Default configuration posture. Review the security of the default build configuration, including enabled cipher suites, protocol versions, key exchange algorithms, and compile-time options that may expose users to risk without explicit opt-in.

      • Protocol compliance. Identify deviations from the TLS 1.2 (RFC 5246), TLS 1.3 (RFC 8446), and DTLS specifications that have security consequences.

      The engagement covers:

      • Mbed TLS at commit 0fe989b6b514192783c469039edd325fd0989806.
      • TF-PSA-Crypto (integrated submodule) at commit 29160dd877d29658279fd683b2ae57b320ddcf09.

      The complete technical report, including our findings and recommendations, is available in Quarkslab's public reports repository.

      Findings

      The table below summarizes the findings of the audit. A total of 5 vulnerabilities were identified: 1 of high severity, 1 of low severity, and 3 informational ones.

      ID | Title | Severity | Perimeter | HIGH-1 | CID Buffer Overflow in mbedtls_ssl_context_load() | High | library/ssl_tls.c:5002
      ---|---|---|---
      LOW-4 | mbedtls_pk_verify() accepts BER-encoded signatures | Low | tf-psa-crypto/extras/pk.c
      INFO-2 | No Anti-Replay Protection for TLS 1.3 0-RTT Early Data | Info | include/mbedtls/ssl.h:5166
      INFO-3 | Mismatch in CMAC cipher support between the documentation and the implementation. | Info | TF-PSA-Crypto documentation
      INFO-5 | compat.sh DTLS 1.2 tests fail on the mbedtls-test Docker image due to IPv6 localhost resolution | Info | mbedtls-test Docker images, compat.sh

      Note: All relevant findings have since been resolved.

      Conclusion

      The audit identified a few vulnerabilities with only two non-informational ones, and the auditors were overall very satisfied with the quality of the product in general, and this version's changes in particular.

      The high and low vulnerabilities are related to a heap buffer overflow and potential signature malleability, respectively, with the second one being identified thanks to the integration of integration of Project Wycheproof test vectors into the test suite.

      An informational finding documents the absence of any anti-replay protection for TLS 1.3 0-RTT early data, a known limitation that is currently not surfaced in the public-facing documentation in a way that prevents inadvertent misuse. Auditors have proposed improvements to the existing fuzzing harnesses and corpora, along with an integration of the #anv test suite into the CI/CD pipeline.

      We would like to thank the Mbed TLS maintainers for their responsiveness and collaboration throughout the audit process, as well as the OSTIF team for their continuous support.

      Further details can be found in our report.

      Further reading

      • OSTIF blog post
   3. 🔗 r/Harrogate Casual football ⚽️ rss

      Me and friend are looking to play football on a Thursday/Friday around Harrogate if anyone can help/recommend anywhere? We already play 7 a side on a Monday but want to play more. Thanks!

      submitted by /u/Conscious-Ad-4738
      [link] [comments]

   4. 🔗 exe.dev Join Us: exe's First Meetup in San Francisco rss

      Maybe it's the years we spent on Zoom? San Francisco seems hungry for in- person events, and we're no exception.

      We're hosting our first technical meetup for developers on Monday, October 26, from 6 to 9pm at the Sentry office in San Francisco. The question of the evening: Are we running too many agents?

      The topic comes from Josh's recent post, ETOOMANYTHINGS? Run Fewer Agents, which sparked some interesting discussion online. We figured it would be fun to continue the conversation and debate in person.

      We've invited a few exe friends to give some talks on the theme:

      • Josh Bleecher Snyder is the cofounder of exe and the person who got this whole conversation started. He'll be talking about whether we're building software factories incorrectly.
      • Beyang Liu is working on amplifying human agency at Amp and previously cofounded Sourcegraph.
      • Josh Wills is an engineer at DatologyAI, with a long history of building developer tools and infrastructure.

      We'll follow the talks with an open Q&A. Bring your questions and opinions to participate in the conversation.

      There will be pizza and drinks, too. A big thank you to Sentry for sponsoring.

      We'd love to have you there. Sign up here: https://luma.com/0qr6bxcw

   5. 🔗 19h/chernobog v6.4.0 release

      Chernobog 6.4.0

      Changes in v6.3.1...v6.4.0.

      • Semantic MBA synthesis beyond the rule catalog — a bounded Z3-backed
        pass simplifies typed 8-, 16-, 32-, and 64-bit expressions across basic blocks,
        with explicit conversions, overlapping register views, byte-addressed memory,
        and proven loop invariants. Replacements require an equivalence proof, followed
        by an independent check of the emitted microcode. Unsupported effects,
        inconclusive proofs, and exhausted budgets preserve the original expression.

      • Nested arithmetic and Boolean reconstruction — bottom-up linear MBA
        reconstruction exposes identities inside larger expressions and cancels
        arithmetic across Boolean subexpressions. Boolean synthesis, modular affine
        fitting, known-bit comparison reduction, and bounded unsigned division
        simplification recover smaller expressions beyond fixed patterns. Constant
        division can become a constant or a threshold comparison when the proven
        quotient range permits it.

      • Caller-context simplification — pure scalar helper calls can become
        constants or smaller symbolic expressions after substituting their actual
        arguments. Local value propagation and facts from both sides of a branch
        expose opaque predicates and constant branches, including after a helper result
        is assigned to a local. Emitted ctree expressions are checked with their casts
        and integer promotions; unsupported or effectful helpers remain calls.

      • Deep deobfuscation — the new Deep deobfuscation (Chernobog) action
        raises the shared semantic-analysis budget from 1 s to 30 s per function.
        Scripts can use chernobog_deep_deobfuscate(ea),
        chernobog_deep_deobfuscate_text(ea), and chernobog_mba_smt_stats(ea).
        These are analysis budgets, not hard limits on total decompiler runtime.
        See semantic MBA synthesis
        for the model and limits.

      • 32-bit saved-register stack stubs — native analysis recognizes bounded
        PE32-style dispatch stubs ending in RET 4 or XCHG [ESP], reg; RET,
        including supported PUSH substitutions. It records the handler target and
        continuation with dependency-tracked proof ownership. When the complete stub
        and handler belong to the same function, early Hex-Rays lowering replaces the
        final return with an explicit pop, any required stack adjustment, and a direct
        jump while retaining preceding stack accesses and register restorations.
        See stack-stub recovery.

      • Call-boundary string inspection — strings observed when rax stops before
        an unmodeled call are available through IDC, inspection JSON, and the evidence
        workspace's Observed strings table. They remain inspection observations;
        decompiler rewrites and proof consumers still require their existing
        completed-run evidence. Entry-input collection examines at most 256 incoming
        references, reports truncation, and supports cooperative cancellation through
        static analysis, input planning, and call-summary collection.

      • WARBIRD diagnostic exploration — a bounded symbolic explorer supports
        native admission profiles for ci, ClipSp, and PEAuth through four IDC functions:
        chernobog_warbird_profiles, chernobog_warbird_start,
        chernobog_warbird_poll, and chernobog_warbird_cancel. It models finite
        successor-key splits, aliased byte memory, supported scalar and legacy 128-bit
        XMM operations, native setup and dispatcher execution, bounded stack growth,
        and selected pool-allocation effects. Counted-store loop relations and guarded
        forward-state joins retain correlated state and memory-effect histories.
        Reports expose unsupported paths and resource limits; database changes
        invalidate results. This is diagnostic exploration only: all corpus entries
        remain partial, no pseudocode is replaced, and whole-entry semantic equivalence
        is not established. See WARBIRD implementation status.

      • Pseudocode stability — caller-context updates run after view navigation
        completes and keep the displayed function, microcode, and text synchronized.
        Pending updates are discarded on function changes or plugin shutdown. Empty
        branch bodies retain the SDK's required placeholder, and zero-width integer
        terms are rejected during call simplification.

   6. 🔗 modem-dev/hunk v0.24.0 release

      Hunk 0.24: beyond the diff

      Hunk 0.24 brings complete-file and directory browsing, a live workspace compass, npm-installed extensions, and version-matched agent skills into your terminal review workspace. Worker highlighting makes startup interaction smoother, while a round of memory fixes keeps large reviews and long-running sessions leaner.

      For npm- and curl-managed installs:

      hunk update 0.24.0
      npm install -g hunkdiff@0.24.0
      

      Homebrew availability will be verified after publication; until then, Homebrew propagation is pending. The commands above select the exact release for npm- and curl-managed installations.

      Explore the source and find your next review

      hunk open shows complete syntax-highlighted files and browses directories with lazy loading, live refresh, and keyboard or mouse navigation. Inspect the surrounding source without manufacturing a diff. The new read-only workspace status view brings together staging state, tracked and untracked changes, and sibling worktrees, with navigation into history and full diff reviews. Static and versioned JSON status output are available too. #1148, #1067

      Automatic diff layout now uses the space actually left after side panes and padding: opening a pane can switch to unified, and closing it can restore split. auto_split_min_width controls the threshold, while scroll_off keeps surrounding context visible during line navigation. Binary files remain reachable through file navigation and sidebar clicks, and the sidebar follows held file-navigation keys without overriding ordinary manual scrolling. #1170, #1109, #1178, #1085

      Keep reviews responsive—and let old reviews go

      Syntax highlighting runs in a worker by default, with grammar warmup during startup to reduce the input stall after the review first appears. Large-diff highlight failures use bounded retries rather than restarting on every scroll. #1105, #785

      Live reloads no longer retain every previous review's files and render state. Nonwrapped reviews reuse geometry across terminal resizes, and keyboard navigation leaves copy-selection content lazy rather than materializing it eagerly. Sessions also stop repeatedly submitting a rejected review to an unchanged daemon while retaining recovery when the review or daemon changes. #1201, #1200, #1202, #1199

      Review reliability improves too: wheel scrolling no longer leaves comments targeting stale lines, notes survive reloads that temporarily omit their files, suspended windows keep their sessions registered, and terminal-editor handoffs release Hunk's stdin reader before launching the editor. #1143, #1164, #1131, #1134, #1165

      Performance note: release benchmarks have no gated regressions against 0.23.0 or beta.1. The known sidebar-follow tradeoff from beta.1 remains relative to beta.0: navigation p95 is 42.74 ms versus beta.0's 36.35 ms, beta.1's 44.55 ms, and 0.23.0's 46.32 ms. This preserves correct sidebar following during held navigation and resizing.

      Easier extensions, agent setup, and shell navigation

      hunk extension install accepts npm packages—including scopes, versions, ranges, and tags—alongside Git sources, without running npm lifecycle scripts. Folder-local package imports work in compiled Hunk binaries. Extensions gain generation-scoped presentation filters and independent left/right pane controls. #1162, #1163, #1118, #1171

      Install agent pointer skills through the skills CLI; hunk skill show supplies the full instructions matched to your installed Hunk version. Bash and Zsh completions help discover commands, flags, and supported values. The note-composer save shortcut is now remappable, and hunk gh --help and the docs cover more of the available review workflows. #1167, #1157, #962, #1186

      Compatibility notes

      • Default theme: github-dark-default is the default again. Set theme = "terminal", pass --theme terminal, or use the theme picker to keep following your terminal palette. This differs from 0.23 and the 0.24 betas. #1195
      • Automatic layout: the default threshold is 160 available diff columns, excluding panes and outer padding. Configure auto_split_min_width or select explicit split/unified mode to override it.
      • Navigation context: scroll_off defaults to five rows; scroll_off = 0 or --scroll-off 0 restores edge-only scrolling.
      • Highlighting: --fast is now a no-op and will be removed in a later release. Windows compiled binaries and custom themes with syntax_scopes continue to highlight inline.
      • Patch validation: nonempty input without recognizable file changes now fails explicitly instead of silently opening an empty review. Genuinely empty reviews have their own message. #1183, #1182
      • Extensions: the public API is version 31. Gate new APIs on hunk.apiVersion when supporting older Hunk versions.
      • Persistent state: Hunk uses the XDG state directory while preserving existing state and global extension locations. Agent notes start hidden; use the review controls to reveal them.
      • Runtime requirements: npm installations require Node.js 22 or newer; standalone binaries do not require Node.js.

      Community contributors

      • @0xferrous fixed combined conflict diffs and plain-text pager output through pipes. #1102, #1112
      • @Ajay-Satish-01 made the note-composer save shortcut remappable. #962
      • @andreifilip123 added the configurable context margin around the current line. #1109
      • @andrewloux improved macOS test portability and kept noted files recoverable across reloads. #1146, #1131
      • @bottercode fixed lockfile refresh during release versioning. #1158
      • @brettinternet added generation-scoped extension presentation filters. #1118
      • @edenbuilds validated extension VCS watch hooks before registration. #1080
      • @elucid fixed installer release lookup, clarified session-selector errors, and sped up terminal-theme refresh. #1140, #1149, #1130
      • @HackAttack fixed annotated-note navigation, wheel-scroll comment targets, and suspended-session registration. #1147, #1143, #1134
      • @igshehata preserved text entered immediately after opening a note composer. #1125
      • @LandonSchropp added hunk-verdict and hunk-backup to the extension directory. #1137
      • @masonmcelvain made worker highlighting the default and warmed grammars during startup. #1105
      • @mikemikimike moved persistent state to the XDG state directory. #920
      • @mvanhorn fixed folder-extension package imports in compiled binaries. #1163
      • @silvioprog added Bash and Zsh shell completions. #1157
      • @strawberry-little-bear corrected terminal-width handling for grapheme Prepend characters. #1153
      • @teepark made automatic layout depend on available diff width and added its configurable threshold. #1170
      • @Lawgk kept the sidebar selection visible during held file navigation and terminal resizing. #1085
      • @rnihesh fixed live reloads retaining every previous review's files and render state. #1201

      All merged pull requests

      • publish v0.23.0 notes by @benvinegar in #1135

      • resolve releases from the apex domain by @elucid in #1140

      • bump taiki-e/install-action from 2.86.3 to 2.87.14 in the github-actions group by @dependabot[bot] in #1139

      • adopt new hunk logo, flat favicon, and brand guide by @benvinegar in #1145

      • explain selector misses instead of protocol-validation-failed by @elucid in #1149

      • refresh terminal colors via direct OSC probe by @elucid in #1130

      • pass the lifecycle, trust prompt and jj source tests on macOS by @andrewloux in #1146

      • Add hunk-mark-read to hunk-extension marketplace by @benvinegar in #1155

      • measure grapheme Prepend scalars with the cluster that follows them by @strawberry-little-bear in #1153

      • compact same-directory rename labels by @benvinegar in #1156

      • add complete-file viewer and lazy directory browser by @benvinegar in #1148

      • Fix/draft note focus transition by @igshehata in #1125

      • render conflicted Git diffs by @0xferrous in #1102

      • handle plain text output through pipes by @0xferrous in #1112

      • add generation-scoped presentation scope API by @brettinternet in #1118

      • bound and surface large-diff highlight retries by @benvinegar in #785

      • Add hunk-guide and hunk-verdict to hunk-extension marketplace by @benvinegar in #1159

      • Highlighting: Make the worker the default and warm it during startup by @masonmcelvain in #1105

      • reveal note composers at the bottom edge by @benvinegar in #1160

      • preserve filter focus when results reappear by @benvinegar in #1161

      • reject non-callable VCS operation watch hooks by @edenbuilds in #1080

      • stop annotated navigation skipping notes drawn outside hunks by @HackAttack in #1147

      • refresh bun.lock when versioning packages by @bottercode in #1158

      • Add LandonSchropp/hunk-verdict and hunk-backup to the extension directory by @LandonSchropp in #1137

      • add scroll_off setting for viewport margin by @andreifilip123 in #1109

      • keep a session connected when a reload leaves out a noted file by @andrewloux in #1131

      • stop wheel scroll and stale hover from drifting comment targets off the highlighted line by @HackAttack in #1143

      • restore comment targets after batched wheel returns by @benvinegar in #1164

      • add bash and zsh shell completions by @silvioprog in #1157

      • release stdin before launching terminal editors by @benvinegar in #1165

      • support managed npm package sources by @benvinegar in #1162

      • add a workspace compass with sibling worktrees by @benvinegar in #1067

      • link GitHub release notes after hunk update by @benvinegar in #1166

      • load folder-local packages in compiled binaries by @benvinegar in #1163

      • let note composer save be remapped by @Ajay-Satish-01 in #962

      • reveal pane edges independently by @benvinegar in #1171

      • distribute version-matched agent skills via skills CLI by @benvinegar in #1167

      • trim verbose README prose by @benvinegar in #1174

      • keep sessions alive while window is suspended by @HackAttack in #1134

      • store persistent state under XDG state directory by @mikemikimike in #920

      • isolate suspension test daemon port by @benvinegar in #1176

      • clarify configuration overrides and examples by @benvinegar in #1175

      • Auto width threshold by @teepark in #1170

      • prepare 0.24.0-beta.0 by @benvinegar in #1177

      • keep binary files reachable by file navigation and clicks by @bottercode in #1178

      • reject unrecognized nonempty patch input by @benvinegar in #1183

      • Add hunk-why to hunk-extension marketplace by @benvinegar in #1179

      • distinguish empty reviews from filtered files by @benvinegar in #1182

      • keep the selected file visible in the sidebar during held navigation by @Lawgk in #1085

      • allow published prereleases in changelog smoke by @benvinegar in #1185

      • correct stale facts and fill gaps across hunk.dev docs by @benvinegar in #1186

      • prepare 0.24.0-beta.1 by @benvinegar in #1187

      • publish 0.24.0-beta.1 notes by @benvinegar in #1194

      • restore GitHub Dark Default as the default theme by @benvinegar in #1195

      • reuse nowrap geometry across terminal resizes by @benvinegar in #1200

      • stop resubmitting rejected reviews to unchanged daemons by @benvinegar in #1199

      • stop reloads from retaining every previous review by @rnihesh in #1201

      • Add hunk-checkpoint to hunk-extension marketplace by @benvinegar in #1189

      • keep copy-selection rows lazy during navigation by @benvinegar in #1202

      • add brand page and logo downloads by @benvinegar in #1203

      • Prepare stable 0.24.0 by @benvinegar in #1205

      Release notes : https://hunk.dev/changelog/0.24/
      Full changelog : v0.23.0...v0.24.0

   7. 🔗 Ampcode News Assign It To Amp rss

      Amp is now an agent in Linear.

      Assigning an issue to Amp starts a new Agent Session in Linear and spawns a new orb. You can also mention @Amp to kick off a session. Amp sends its response back to the same session and replies to messages sent along the way. The Agent Session also appears in your Amp sidebar and is fully viewable in Amp.

      Assign Amp an issue in Linear.

      

      Follow its progress in the Agent Session.

      

      Then open the same conversation in Amp.

      

      To get started, install the Amp agent in your Linear workspace and connect your Amp account to the Linear MCP in Settings → MCP & Integrations.

      

      Read the docs to learn more.

generated: October 22, 2026 at 18:56:11