🏡

July 24, 2026
1. 🔗 r/reverseengineering Fortinet ppl bypass rss
  
  submitted by /u/nanaynunay
  [link] [comments]
2. 🔗 3Blue1Brown (YouTube) The 64 sugar cubes puzzle rss
  
  See all monthly puzzles: https://momath.org/mindbenders/
3. 🔗 r/reverseengineering The quirks of CPU extended mode in “Comanche: Maximum Overkill” (1992) rss
  
  submitted by /u/alberto-m-dev
  [link] [comments]
4. 🔗 r/reverseengineering Workshop map for MECCHA CHAMELEON is a malware dropper (full breakdown) rss
  
  submitted by /u/feintbe
  [link] [comments]
5. 🔗 earendil-works/pi v0.82.0 release
  New Features
  - Constrained tool sampling — Tools can prefer or require strict JSON Schema sampling or use OpenAI Lark/regex grammars, with model capability metadata preventing unsupported requests. See Constrained Sampling for Tools.
  - OpenRouter and Kimi Code sign-in — Use /login to authorize OpenRouter or a Kimi Code subscription without manually configuring API keys. See OpenRouter.
  - Session-aware, streaming bash integrations — Bash tools receive current session/model metadata, while direct RPC bash commands stream correlated output. See Bash Tool Session Environment and RPC bash events.
  Added
  - Added inherited Tool.constrainedSampling with strict JSON Schema (prefer/require) and OpenAI Lark/regex grammar variants across OpenAI, Anthropic, Amazon Bedrock, Google Gemini, and Mistral. See Constrained Sampling for Tools.
  - Added inherited supportsGrammarTools and supportsStrictTools compatibility flags, expanded supportsStrictMode coverage, and generated model capability metadata to gate constrained sampling.
  - Added inherited Kimi Code subscription OAuth login for the Kimi For Coding provider, including device authorization and automatic token refresh (#6935 by @zaycruz).
  - Added inherited OpenRouter OAuth PKCE login through /login, minting a user-controlled API key. See OpenRouter (#6927 by @rsaryev).
  - Exposed PI_SESSION_ID, PI_SESSION_FILE, PI_PROVIDER, PI_MODEL, and PI_REASONING_LEVEL to commands run by built-in and factory-created bash tools. See Bash Tool Session Environment.
  - Added streaming bash_execution_update events for direct RPC bash commands, correlated with request IDs. See RPC bash events (#6971 by @ananthakumaran).
  Changed
  - Changed inherited generated model catalogs to expose only provider-verified reasoning effort levels from models.dev (#6928 by @davidbrai).
  Fixed
  - Fixed inherited DNS lookup failures such as getaddrinfo, ENOTFOUND, and EAI_AGAIN to trigger automatic assistant retries (#6946 by @christianklotz).
  - Fixed inherited OpenRouter Anthropic cache breakpoints to advance through tool results and enabled cache control for ~anthropic/*-latest aliases (#6941 by @mteam88).
  - Fixed inherited OpenAI Codex WebSocket sessions to retry once without a missing previous-response continuation after previous_response_not_found errors (#6955 by @davidbrai).
  - Fixed TUI debug and crash logs to respect custom agent directories instead of always writing under ~/.pi/agent (#6958 by @davidbrai).
  - Fixed slow Ctrl+G external-editor startup when the system temporary directory contains many entries (#6903 by @christianklotz).
  - Fixed startup resource display to preserve relative paths for sibling npm extensions loaded by a package (#6964 by @davidbrai).
  - Fixed compaction and branch-summary requests to use fresh routing session IDs with prompt caching disabled where supported (#6618 by @tmustier).
  - Fixed explicit self-updates when PI_SKIP_VERSION_CHECK is set (#6977).
  - Fixed scoped model IDs containing brackets to resolve as literal exact matches before glob matching (#6210).
  - Fixed inherited OpenAI and Anthropic provider retry waits to honor abort signals and configured delay limits (#6980 by @petrroll).
  - Fixed fresh installs from preferring bundled model catalogs over newer remote catalogs because package file mtimes were newer (#7016 by @davidbrai).
  - Fixed inherited editor scroll indicators overflowing narrow terminals (#7015 by @christianklotz).
  - Fixed llama.cpp models to use the loaded context window as their output token limit instead of capping it at 16K (#7034 by @christianklotz).
  - Fixed release source archives to include the generated provider model data used to build standalone binaries.
  - Updated the packaged protobufjs dependency to 7.6.5 to address GHSA-j3f2-48v5-ccww (#7005).
  - Fixed /copy on Wayland to fall back to X11 or OSC 52 when wl-copy fails (#7009 by @rkfshakti).
  - Fixed /model to reload updated models.json configuration when opening the model picker (#6999).
6. 🔗 r/reverseengineering Escaping Claude Cowork’s local VM sandbox via CVE-2026-46331 rss
  
  submitted by /u/natcoba
  [link] [comments]
7. 🔗 @binaryninja@infosec.exchange Last chance to register for our Firmware Reverse Engineering class next week! mastodon
  
  Last chance to register for our Firmware Reverse Engineering class next week! Some embedded architectures are completely unlike what we're used to from x86, ARM, or MIPs, and we want you to know about them: https://shop.binary.ninja/products/fre- july-26
  
  https://www.youtube.com/shorts/0AQPnGtivko
8. 🔗 obra/superpowers v6.2.0 release
  v6.2.0 (2026-07-23)
  
  Subagent-Driven Development
  
  Two structural changes to how SDD tracks progress and closes out review findings, both developed against live eval campaigns.
  - The workspace is now plan-scoped. .superpowers/sdd/ had no plan identity and no end-of-life: a follow-up plan in the same working tree could read the previous plan's ledger as its own progress (observed in the wild, with multiple contamination rounds and ad-hoc workarounds). sdd-workspace now requires the plan file and resolves a per-plan directory, .superpowers/sdd/<plan-basename>/; task-brief and review-package write into their plan's directory (review-package gains the plan file as its first argument); the ledger names its plan on its first line; and the workspace is deleted once the final review is clean — git history is the durable record. Baseline evals showed controllers already refused foreign ledgers, but at a cost of 6–13 tool calls of cross-plan git forensics per resume; plan-scoping makes the answer structural instead. (25/25 baseline and GREEN eval runs documented in docs/specs/ and docs/plans/.)
  - The review-fix loop resumes the implementer. The lifecycle restructure gives fix rounds resume-the-implementer semantics instead of fresh dispatches, adds a scoped re-review prompt (re-review-prompt.md) so the re-reviewer checks the fixes rather than re-reading the whole task, and installs a five-round circuit breaker with controller adjudication when it trips. SKILL.md reorganizes by lifecycle, and its Red Flags convert to the house rationalization-table form.
  Skills
  
  A branch-wide compression campaign: recap sections, social proof, and benefits-selling prose aimed at a reader who has already invoked the skill are gone, with every load-bearing argument folded into a rationalization-table row or moved to its point of use. Each cut was micro-tested with subagent probes, and the one cut that measurably degraded behavior was reworked rather than shipped.
  - testing-anti-patterns.md is now writing-good-tests.md. The TDD reference doc is rebuilt as a positive catalog — six rules that lead with the GOOD example — and absorbs a falsifiability discipline: name the production change that would fail the test, derive expectations independently of the code under test, and a closing mutation check. It closes two holes by name: the string-presence trap (grep-style tests on scripts, skills, and prompts counterfeit falsifiability — the observable is behavior, never text) and the change-detector trap (a constant assertion can fail and still protect nothing), each with a hard stop in the gate function. Trivial code and human prose earn no test; the trigger broadens from "adding mocks" to any test writing.
  - TDD's "Why Order Matters" rebuttals survive as rationalization rows. Deleting the section outright measurably degraded test-first behavior under "just write it, tests after" pressure (control 8/10 → treatment 5/10, corroborated on Claude and Codex), so each prose rebuttal now lives in its Common Rationalizations row — the section is gone but the arguments fire where an agent hits them mid-rationalization.
  - finishing-a-development-branch no longer offers to discard your work. The completion menu dates from when throwing away branches was routine; "Discard this work" next to "Merge" advertised destroying finished, passing work. Discard survives as an explicit-request-only path with the same typed-confirmation ritual. The same pass made PR creation forge-agnostic (your forge's CLI or the URL printed on push, not a blessed list of tools) and fixed a real bug: the worktree path was recomputed after cleanup had already changed directory, so provenance checks never matched and cleanup silently no-oped.
  - Recap and persuasion prose removed across the library. brainstorming, systematic-debugging, dispatching-parallel-agents, verification-before-completion, executing-plans, subagent-driven-development, requesting-code-review, receiving-code-review, using-git-worktrees, writing-plans, and writing-skills all drop their Bottom Line / Key Principles / Real-World Impact / Advantages sections; using-git-worktrees and finishing-a-development-branch convert their guard sections to the house Excuse/Reality rationalization table.
  Windows
  - The SessionStart hook now dispatches via Git Bash. The hook's command string starts with a quoted path, which broke both shells Claude Code might hand it to: PowerShell parsed the quoted string as an expression and died with a parser error (#1751), and cmd.exe's quote-stripping rule truncated the command when the profile path contained a metacharacter like ( (#1918) — either way the bootstrap silently never loaded. The hook now declares shell: "bash", which Claude Code ≥ 2.1.81 resolves to Git for Windows directly, and which surfaces an actionable install prompt when Git Bash is missing. Older Claude Code versions ignore the unknown key and behave as before. Verified end-to-end on Linux, Windows 11 with Git Bash under a hostile path, and Windows 11 without Git Bash.
  Harness Support
  - Gemini CLI support is restored. The v6.1.0 removal (on the news that Google had EOLed the Gemini CLI) was premature; the install docs and the gemini-tools.md tool-mapping reference are back while permanent removal gets a proper evaluation. (#1959)
  Fixes
  - find-polluter.sh actually finds test files now. find . emits ./-prefixed paths, so the documented -path "src/**/*.test.ts" pattern matched nothing — and wc -l on empty input then reported "Found 1". Fixed the prefix mismatch (#2008, #2011), plus two follow-ups: a caller-supplied ./-prefixed pattern no longer double-prefixes into a never-matching form, and **/ is also matched collapsed so tests directly under the base directory (src/top.test.ts vs src/**/*.test.ts) aren't silently skipped. The script gains a deterministic test suite.
  - The Codex package script works beyond macOS. Deterministic-metadata tar flags were bsdtar-only spellings, staged file modes depended on two umasks canceling out, and the test's timestamp assertion parsed bsdtar's column layout in a US timezone. GNU tar now gets equivalent flags producing byte-identical headers, modes are pinned canonical, and the test asserts mtime via tarfile.
  - SDD's skill test no longer flakes. The file's worst case exceeded the runner's per-file ceiling (raised to 900s), and the assert helpers matched free-form model prose case-sensitively; matching is now case-insensitive and assert_order dumps output on failure so the next flake is diagnosable.
  - Docs and test cleanup after the v6.1.0 reference pruning. Dead links to the deleted claude-code-tools.md/copilot-tools.md are replaced with the current architecture (#1969), a dangling #subagent-support anchor in the Antigravity reference is dropped (#2010), and the Antigravity/Pi mapping tests assert only the surviving harness-specific mappings — scoped to the table so they fail again if it's deleted.
9. 🔗 New Music Releases Above & Beyond - One Mix with Above & Beyond rss
  Above & Beyond - a new release is available:
  - 2026-07-24: One Mix with Above & Beyond (Album)
  Amazon: Canada | Deutschland | France | United Kingdom | United States
  
  Visit muspy for more information.
10. 🔗 New Music Releases The Revivalists - Get It Honest rss
  The Revivalists - a new release is available:
  - 2026-07-24: Get It Honest (Album)
  Amazon: Canada | Deutschland | France | United Kingdom | United States
  
  Visit muspy for more information.
11. 🔗 New Music Releases The HU - Hun rss
  The HU - a new release is available:
  - 2026-07-24: Hun (Album)
  Amazon: Canada | Deutschland | France | United Kingdom | United States
  
  Visit muspy for more information.
12. 🔗 exe.dev tailmix: Connect to Multiple Tailnets at Once rss
  
  Tailscale is one of those magical technologies that I can no longer imagine living without. Its use cases range from homelab setups to enterprise workloads spread across complex, disparate environments. At exe, we use it to connect much of our internal infrastructure.
  
  That said, there are points of friction. One of my pet peeves is having to switch tailnets whenever I want to briefly connect to Home Assistant or Frigate to see who’s at the door while working on exe’s infrastructure. Tailscale’s fast user switching helps, but switching still disconnects one tailnet before connecting the other. That disrupts existing connections, takes a few seconds, and requires me to remember to switch back.
  
  Why can’t I just be connected to multiple tailnets at the same time?
  
  A few technical complications make it tricky, starting with the fact that Tailscale allocates IPv4 addresses independently within each tailnet. This means two nodes in two different tailnets can end up with the same IPv4 address. If both tailnets were connected simultaneously, the address alone wouldn’t tell the client which node I intended to reach.
  
  I could disable IPv4 and use IPv6 exclusively, but that still doesn’t work everywhere. It’s getting better, but the long tail is, well, long. Disabling IPv4 requires updating the Tailscale policy file and passing some pain along to my teammates, which feels unjustified.
  
  Node sharing has similar challenges. Tailscale does the work of making sure those IPs don’t collide, but it requires that I be an admin on both tailnets, and I’d have to individually share every device I wanted to reach. As my kid is fond of saying: I don’t want to!
  
  A couple of weeks ago, I wondered whether I could have an agent write me a new Tailscale client that would let me connect to multiple tailnets at once. As usual, I spun up a new VM on exe and told Shelley about my problem, and we went back and forth on the design until I was convinced the solution would work for the vast majority of use cases.
  
  The solution was fairly straightforward: spin up a couple of tsnet.Server instances, put them behind a single TUN interface, assign each peer node in each tailnet a new IPv4 from a locally configured pool such as 10.58.0.0/16, and hijack MagicDNS to return those IPs. Traffic sent to one of them is then routed through the corresponding tailnet.
  
  It worked the first time I tried it. All of the Tailscale policies worked just as they should, and I didn’t have to implement any of that, as the upstream tsnet.Server is a full-fledged Tailscale client already.
  
  The result is tailmix, an independent, open-source client that lets one machine connect to multiple tailnets simultaneously. The source, installation instructions, and current limitations are all in the repository—or you can ask Shelley to tell you all about it.
  
  I still have two tailnets, two identities, and two separate sets of policies. The difference is that now my laptop no longer makes me choose between them.
13. 🔗 Armin Ronacher Codeberg Divides rss
  
  Codeberg recently changed its terms to exclude projects that are largely written with generative AI. Since I want GitHub to face competition I have thoughts.
  
  Codeberg is entirely within its rights to do this. It is an association with members and a democratic process, and that process produced a result. But democracy is a way of making a decision, not a guarantee that the decision is inclusive, wise, or even good for the people already depending on it. A majority can still decide that certain projects and people no longer belong.
  
  GitHub's governance has never been democratic and there is plenty about the platform that I dislike. Yet democracy is not the main property I need from infrastructure. I need it to be predictable, dependable, and reasonably neutral towards the legal Open Source software hosted on it. A democratic provider without a clear constitution can be worse at those things than a corporation.
  
  The actual wording makes this more difficult. The terms prohibit projects that mostly consist of code written by generative AI tools. In an actively developed codebase, what does "mostly" mean, and who can still tell? I could not reliably assign authorship percentages to many of my own recent projects. The line is open to interpretation precisely where it needs to be enforceable. In practice the center will probably lose out, as it has a bias.
  
  A harsher line would probably be preferable. If Codeberg wants no LLM involvement, it should say so. If it wants to prevent autonomous repository spam and abusive resource consumption, it should write rules for those instead. The current middle ground delegates too much of the policy to moderators and community norms. I'm currently assuming the community around it draws a much harsher social boundary, making projects and maintainers unwelcome even when they technically comply.
  
  It is a real shame that the Open Source and Free Software communities are splitting this deeply over LLMs and agents. There are serious questions about copyright, labor, energy use, slop, and maintainers drowning in generated contributions. But these tools are also becoming part of how software is made. The Open Source world needs to figure out how to engage with that future, not just divide into camps. More importantly, LLMs if done and used well, should be welcome to all of us. They could be used to reclaim control and power, away from large corporations and institutions.
  
  As I mentioned before, I want GitHub to face true competition in the Open Source space. I would particularly like some of it to come from associations rather than another large corporation. As a European project, Codeberg naturally matters to me even more. It can choose to be a smaller community with a stronger political identity, but that is a different ambition from being a broad and dependable European alternative to GitHub.
  
  I wish Codeberg were more forward-looking here: willing to host the Open Source software of tomorrow, not only software made in the ways its community approves of today. It has every right to make the choice it made, but I just do not think it is a good one.
July 23, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-23 rss
  IDA Plugin Updates on 2026-07-23
  
  New Releases:
  - plugin-ida v3.25.2
  Activity:
  - augur
    
    6ceeb9e9: test: improve unit tests
  - binsync
    
    0b1b449b: Allow the server to correctly track which users are connected. (#519)
  - DeepExtractIDA
    
    7dbdbbb7: Add v3 schema (function addresses, imports/globals tables, EA-prefixe…
  - disrobe
    
    e9361488: harden pyfreeze parser fuzz coverage
    
    313fddfc: native: keep sign and zero extended aarch64 indexes out of array aggr…
    
    34009fa0: native: model aarch64 sign and zero extended 32-bit index registers s…
    
    b40470b6: harden scriptlang parse paths
    
    b1ac85f9: native: decode aarch64 scaled register-index addressing [base, xindex…
    
    315fa0aa: native: accept aarch64 bitmask and move immediates above the signed r…
    
    c56a8857: native: decode aarch64 umull and smull as 32-by-32 into 64 widening m…
    
    5a959c91: native: decode the aarch64 vector bic as an elementwise and-not
    
    43c12a25: harden py disasm fuzz paths
  - haruspex
    
    ae585c22: test: improve unit test names
  - hrtng
    
    59dba8e5: - autorename: revert "ignoring nice names"
  - ida-hcli
    
    c80e825c: fix: address install script review findings
    
    d9d446a0: fix: use direct GitHub download URLs in install script
    
    87aa5b36: fix: use None check for falsy plugin setting defaults in non-interact…
    
    489bc306: fix: rename running binary aside before replacing during update (#261)
    
    2bda7356: fix: detect existing install dir before attempting ida install
    
    6542169d: fix: skip repo fetch for plugin subcommands that don't use it
    
    5542eaff: Merge pull request #253 from HexRaysSA/gha-update
    
    841ca17e: Fix zizmor findings
    
    93d3ecb4: Update and pin GHA
  - IDA-Plugins
    
    ba11c7d4: Add new plugins and extend existing analysis features
    
    65f6c8b7: Consolidate IDA plugins into a single repo
  - ida-pro-mcp
    
    e2664060: Add host tests for recent isolation and safety fixes.
    
    4d5bc997: Fix disasm start address and funcs write synchronization.
    
    d0a4dc4b: Scope insight indexes to sessions and IDBs.
    
    fab177c7: Use high-entropy continuation tokens for truncation.
    
    f9908f35: Isolate blackboard workspaces per analysis session.
    
    436c1394: Clarify agent contract docs and enforce SKILL sync.
    
    7538ef2e: Tighten batch and graph result semantics.
    
    6c4fe5d0: Align semantic indexing with search entry-EA windows.
    
    652ff78d: Fix blackboard scoping and workspace brief hygiene.
    
    1aa49846: Harden policy fail-closed paths and installer packaging
    
    b26fcad1: Gate destructive session actions and fix high-impact tool crashes
    
    2341c843: Harden MCP session ownership for tools, switch, and background jobs
  - Luc-Nhan
    
    3dbaa907: feat(glm): distinguish Standard vs Coding Plan endpoints
    
    ba459fab: Merge remote-tracking branch 'EliteClassRoom/master'
    
    0e11cde0: adding emulation to rikugan
    
    08e49f93: fix(settings): show GLM in provider dropdown and auto-config on select
    
    2e9abc07: feat(glm): add GLM-5.x reasoning resilience
  - plugin-ida
    
    67ec8db7: Merge pull request #171 from RevEngAI/refactor/v3-collections-endpoints
    
    8187b3f0: refactor(PLU-325): use v3 collections endpoint for search
  - quokka
    
    0f01c85b: Merge pull request #134 from DarkaMaul/dm/fix-115
    
    9220e374: Merge pull request #133 from DarkaMaul/test/relax-ida93-inport-control
  - ToCode
    
    b6d7f1c3: Merge pull request #12 from buzzer-re/dev/fix-deadlock
    
    3839dd57: Make the atomic-write lock test type-check on Linux
    
    35b0f392: Fix Windows-only mypy and test failures so ci-local passes
    
    ea741be8: Drop the redundant Command log line from the CLI export path
    
    301e0639: Retry atomic file replace to survive transient Windows locks
  - twdll
    
    3db4cf22: build(gh-actions): fix more submodules
2. 🔗 modem-dev/hunk v0.17.4 release
  What's Changed
  - fix(ui): restore threaded rendering on macOS by @benvinegar in #539
  - fix(review): save draft notes exactly once under rapid Ctrl+S by @endotakuya in #581
  Full Changelog : v0.17.3...v0.17.4
3. 🔗 r/reverseengineering Remus Stealer Analysis: Fileless Execution, In-Memory Payload Extraction & C2 Discovery rss
  
  submitted by /u/StructBreaker
  [link] [comments]
4. 🔗 The Pragmatic Engineer The Pulse: New trend - concern about massive increase in code review load rss
  Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics of last week 's The Pulse issue . Full subscribers received the article below seven days ago. If you 've been forwarded this email, you can subscribe here .
  
  One thing I am hearing that's top of mind for many engineering leaders is what is being done to deal with the continuous increase in code review load. It's been a topic for a while, and more such conversations seem to be taking place.
  
  For me, it began in January, when Opus 4.5 and GPT 5.4 started to write more and better code at most companies. Around then, Director-level folks started talking about the bottleneck of building software moving from coding to the review phase.
  
  There 's been a boom in AI code review tools to deal with the increase in load since February, and an explosion of experimentation with and adoption of dedicated AI code review tools like CodeRabbit, Greptile, Qodo, SonarQube (now also Gitar). There's also tools offered by coding harnesses themselves like Claude Code review, Cursor review, GitHub Copilot review. And then tools previously not involved in code reviews - but which have context on the codebase - are also adding this, like Sentry 's Seer AI reviews, Linear code reviews.
  
  Larger companies are building in-house tools to improve the code review experience. Uber's Code Inbox is one case:
  
  Uber 's Code Inbox. From How Uber uses AI for software development
  
  Smart assignments are a feature inside Code Inbox for having reviews progress:
  
  Smart assignment settings for Code Inbox
  
  Then there's Risk Profiles which estimate the impact of a change, and encourage devs to pay extra attention to risky ones:
  
  Code Inbox tries to estimate the risk of a code change, and bring attention to it
  
  We covered how Uber uses AI for software development, and it's not just Uber: companies like Cloudflare (AI Code Reviewer), Faire (Fairey), and HubSpot (Sidekick) and many others have also built tools to make their code review flows more fluid, after finding that an in-house implementation worked better than integrating a vendor.
  
  Another approach is thinking about how to verify code, instead of reviewing. This is easier said than done; in theory, thorough testing should be able to verify that code works as expected. But how much testing is 'thorough'? What type of tests are we talking about? Integration and end-to- end as well? What about fuzz testing? Or formal methods? What about verifying that new tests exercise the functionality as expected? And how do we connect all of this with observability?
  
  Too much thorough code review is burning out engineers, and resulting in sub-par code reviews. I hear a lot anecdotally that devs see others as no longer able to review code with intent, whereby, if the AI code review has no real comments, they just approve it. Meanwhile, those devs who put the same effort and energy into code review as before feel overloaded by AI slop PRs sent their way.
  
  The problems exist, and the solutions feel more like experiments.
  
  What are you seeing inside your company, and how are you dealing with the increase in code reviews? Share your ideas for practical, workable "replacements"?
  
  Read the full issue of The Pulse this excerpt is from, or check out the latest The Pulse from today. Today's issue covers:
  1. Moving video podcasts off Spotify due to constant reliability issues
  2. "Kimi K3" moment & a US lobby for closed-source AI models
  3. AWS laughs off huge billing error
  4. Industry Pulse
  Read the full issue here
5. 🔗 Hex-Rays Blog Teams: Git-native Versioning & Collaborative Reversing rss
  
  Teams is a collaboration add-on for IDA Pro recently revised to focus on two pillars: version control and team collaboration with features like Deep Links. It brings Git-based versioning and real-time sharing directly into IDA, so reverse engineering teams can work together on the same binaries without losing work, duplicating effort, or managing files manually.
6. 🔗 @binaryninja@infosec.exchange Current Binary Ninja newsletter subscribers are automatically entered. New mastodon
  
  Current Binary Ninja newsletter subscribers are automatically entered. New subscribers who sign up during the giveaway will also be entered for remaining drawings. Sign up for our newsletter here: https://v35.us/dn6rcg5
7. 🔗 @binaryninja@infosec.exchange 10 years ago today, we shipped the first build of Binary Ninja to our mastodon
  
  10 years ago today, we shipped the first build of Binary Ninja to our customers! We’re kicking off our anniversary celebration by giving away a Binary Ninja Non-Commercial license. See the full giveaway schedule: https://binary.ninja/10years
8. 🔗 r/reverseengineering Transformers Forged To Fight Revival Offline Version Updated rss
  
  submitted by /u/GeamzAngryBirds1
  [link] [comments]
9. 🔗 pydantic/pydantic-ai-harness v0.10.0 (2026-07-22) release
  What's Changed
  - feat: add ModalSandbox for isolated cloud sandboxes by @strawgate in #269
  - feat: Macroscope CLI code-review capability by @strawgate in #350
  - Fix step persistence snapshot after completed tool boundary by @nmoturi in #374
  - Fix ClampOversizedMessages clamping typed ToolCallPart subclasses (ToolSearchCallPart, LoadCapabilityCallPart) by @dsfaccini in #411
  - fix(memory): scope-qualify injection marker so multiple Memory capabilities coexist by @sevakva in #409
  - feat: add LocalStack capability for emulated AWS environments by @strawgate in #268
  - StepPersistence: drop the provider-validity gate, single error-save site, snapshot state classification by @dsfaccini in #412
  - Harden LocalStack capability after post-merge review by @dsfaccini in #425
  - docs(agent): capability CI scoping, post-merge resync, external-service refresh by @dsfaccini in #423
  - Fix release job silently skipping on tag pushes by @dsfaccini in #429
  - Actually fix release skipping on tag pushes: opt out of skipped-ancestor propagation by @dsfaccini in #430
  New Contributors
  - @nmoturi made their first contribution in #374
  - @sevakva made their first contribution in #409
  Full Changelog : v0.9.0...v0.10.0
10. 🔗 Console.dev newsletter Databasement rss
  
  Description: Database server backups.
  
  What we like: Manage database (MySQL, Postgres, MongoDB, SQLite, Redis, etc) backups through a web UI. Supports local, S3, SFTP locations and connections to sources through SSH. Can be automated via an API and MCP server.
  
  What we dislike: No fine-grained user permissions. UI looks a bit vibe-coded.
11. 🔗 Console.dev newsletter Neko Master rss
  
  Description: Network traffic dashboard.
  
  What we like: Real time visualization of network traffic through a minimal PWA. Pulls data from the network gateway (OpenWrt, Linux, router, etc) through an agent or by directly connecting to the gateway. Runs as a simple container. Does domain, IP, proxy stats with trends.
  
  What we dislike: Data is stored in SQLite by default, which is a good place to start, but you can connect to Clickhouse for more robust storage.
12. 🔗 Drew DeVault's blog AI in Linux rss
  
  The role of AI tools (LLMs, mainly) in Linux is under discussion, or it was, until Linus Torvalds “put his foot down” in support of the use of AI in Linux kernel development.
  
  I can identify two major ways in which AI is used for Linux kernel development: authoring code and reviewing code. There are, at the time of writing, just over 1,200 kernel commits with an “Assisted-by” tag, from September 2025 to the present, most of which indicate patches which were written or assisted by LLM tools.
  
  The second important use of AI for Linux comes with a new code review tool called Sashiko, which generates code reviews for patches considered for various subsystems. Sashiko ignited the current debate on AI in Linux because it pushes the envelope on AI in Linux: people who oppose or do not want to use AI could previously just refrain from using it to write their patches, but now there is a growing expectation that anyone who wants to contribute to Linux will have to interact with Sashiko or other AI tools like it to iterate on AI-generated feedback on their work.
  
  One of the major lines of this discussion in the Linux kernel community has been with respect to the ethical considerations of the use of LLMs. Linus shuts this line of reasoning down entirely, firmly grounding the discussion in technical merits and rejecting any political discourse on the matter:
  
  The kernel project has been and will continue to be about the technology.
  Sure, the social angle of working on open source is important and often a very motivating part of the project, but in the end that’s a side benefit, not the point of the project.
  This is NOT some kind of “social warrior” project, never has been, and never will be.
  In the kernel community we do open source because it results in better technology, not because of religious reasons.
  
  This argumentation is disingenuous and hypocritical. Linux is a political project and Linus is a political actor. Consider the use of the GPLv2 for licensing Linux. One can argue from technical merits – for instance, the copyleft nature of the GPLv2 pushes people, and in particular commercial entities, to upstream their drivers and other contributions into the Linux kernel. This contributes to the technical excellence for the kernel as a result.
  
  But is this not a political choice, and a political act? The purpose of this choice is to influence the behavior of others and to advance the interests of the kernel ahead of their own. And Linus stuck to this decision for political reasons when GPLv3 was introduced, reasoning from morality and ethics when objecting to the license and the manner in which it was deployed, and called for a tacit boycott of the FSF.
  
  Linus, and Linux, wields a tremendous degree of power and influence over the world, and it should be wielded responsibly. When Linus says the following:
  
  Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it.
  Or just walk away.
  
  I find it completely disingenuous. Linus is surely aware that, for all practical purposes, Linux cannot be forked. It is the world’s largest software project, and one of the most well-funded, too. The institutional knowledge among its contributors, the prospect of keeping up with the blistering pace of change, or even putting together a group of people with the time and funding to understand and maintain even a fraction of the kernel’s code independently of upstream, is, quite simply, intractable. Linus knows, this, too – it’s an explicitly cited reason for decisions like the use of the GPL, GPL-only symbols, and the unstable internal kernel ABI: to make the process of independently maintaining a fork of the kernel as difficult as possible.
  
  People are right to petition Linux upstream to amend its behavior and policies before resorting to the impossible. Working on Linux requires practicing politics, both internally – see for example Linus’ response to the discussions around bcachefs, which had high technical excellence and low social/political competence – and at the intersection of Linux and the rest of the world. Therefore, we must table political, moral, and ethical arguments when we discuss how we go about the work. It’s a cheap, weak argument to direct the discussion away from political and ethical considerations when it wouldn’t serve your point and to table it when it would.
  
  I’m willing to believe that the LLM-powered Sashiko code reviews provide a lot of good insights. However, to address just one externality of this tool, consider that AI companies are driving up the price of consumer hardware. An AI powered code review may improve a patch, but that patch won’t be of much use to the increasingly large cohort of people who are being priced out of the hardware they could run Linux on to enjoy the better patch.
  
  Looking at it from another angle: how many tons of CO₂ added to the atmosphere or liters of fresh water supplies disrupted is a tolerable price for a better code review? Temperatures during heat waves are exceeding 50°C in India, causing tens thousands of deaths. The AI built-out is by far the fastest growing energy consumer in the world, and they’re being built with fossil fuels, or drawing green energy demand away from replacing the fossil fuels depended on by other industries. The same process is pricing regular people out of the energy they need to power their air conditioner during those heat waves and the technology it enables is pushing them out of the labor market and into poverty.
  
  These externalities are very real, and are affecting a lot of people, including Linux kernel contributors and maintainers, and their friends and families, who are trying to bring these problems to Linus’ attention.
  
  And what of the intangible effects of the use of these tools in Linux? Linux is lending some of the project’s immense influence towards legitimizing the makers of these tools, and Linus’ insistence on focusing narrowly on the technical applications of these tools is a generous gift to them. They will be sure to mention his support in boardrooms, meetings between lobbyists and governments, and anywhere else it will advance their interests.
  
  It’s fair to ask: what are those interests, and what are they doing with this influence?
  
  Google CEO Sundar Pichai pictured at Donald Trump’s inauguration, together with other influential commercial leaders in AI. Sashiko primarily depends on Google Gemini for Linux kernel code reviews.
  
  There are a lot of smart, passionate people who care about these kinds of questions. Where is the technical excellence in refusing to do this moral calculus, refusing to allow anyone else to do so, and driving away the talented Linux contributors who care about these problems? Linus Torvalds, the Linux community, and all of our communities should have the courage and insight to address these dimensions of the AI question honestly and in good faith.
13. 🔗 Filip Filmar The FPGA Hardware Interview: A Topic Guide with Questions and Exercises rss
  
  Interviews for FPGA and digital-design roles draw from a stable, well-defined body of knowledge, yet candidates routinely stumble on it because the questions are asked crisply and must be answered under pressure. I am publishing a preparation guide for exactly that situation: a 29-page report, “The FPGA Hardware Interview”, organized as a sequence of topic reviews, each followed by interview-style questions with model answers and, for the design topics, coding exercises solved in both VHDL and SystemVerilog.
14. 🔗 Ampcode News Event Driven Orbs rss
  Amp's orbs can now receive requests and react to events outside Amp.
  
  That means an orb can wake up when CI fails on GitHub, when someone opens a Linear issue, when a monitor raises an alert, or when an event arrives from Discord. If it can send an HTTP request, it can wake an orb.
  
  More Ways to Wake an Orb
  
  GitHub issues are just one example. You can use the same pattern to:
  - Investigate every CI failure on main and post the findings to Slack.
  - Watch for new releases of your dependencies, then review the changes and open an upgrade PR.
  - Start a fresh thread when someone opens a Linear issue, then comment with a fix or report.
  - Turn a bug report from Discord into a reproduction and pull request.
  - Resume a rollout when a deployment or security scan reports back.
  The event decides when the orb wakes up. You decide what it does next.
  
  From a GitHub Event to an Orb
  
  Here is the whole setup. Start a thread in an orb for your repository and tell Amp which events to watch and what to do with them:
  
  Amp turns that request into a project-specific plugin. It scopes the listener to the repository and events you asked for, verifies GitHub's signature, deduplicates deliveries, and starts a read-only orb thread with trusted event metadata.
  
  Then Amp loads the plugin and registers its durable endpoint:
  
  If the orb's GitHub token can administer repository webhooks, Amp connects the endpoint for you. In this case it could not, so Amp gave us one manual step without printing the private URL or signing secret into the thread:
  
  A Wild Issue Appears
  
  Once the webhook is active, someone opens issue #57:
  
  GitHub sends the signed event to Amp. Amp verifies it and starts a fresh orb thread with the trusted repository, event, issue, and actor metadata. The issue itself remains untrusted input, not agent instructions:
  
  The new thread inspects the current issue and relevant code, then reports what it found:
  
  The typo is real, appears once, and only affects secondary menu text. Now the same workflow runs for every issue and pull request event while the original orb sleeps.
  
  How It Works
  
  Webhooks work through the Amp Plugin API. When you ask Amp to listen for an event, it creates a plugin in the orb and calls amp.createWebhook to register a durable endpoint for that thread. Then it loads the plugin and gives you the URL to connect to GitHub, Linear, Discord, or another service. If the orb already has access, Amp can connect it for you.
  
  When a request arrives, Amp stores the event and wakes the orb. The plugin validates and filters the payload, then handles it using the instructions you gave Amp. The URL stays the same across plugin reloads and orb restarts, so the orb does not need to keep running while it waits.
  
  React to Events However You Want
  
  amp.createWebhook gives the plugin a handler, not a fixed workflow. That handler is ordinary TypeScript with access to the rest of the Plugin API. The handler can:
  - Continue the owning thread with its context intact by appending the event to ctx.thread.
  - Start a fresh thread in an orb with amp.getBuiltinAgent(...).createThread({ executor: 'orb' }).
  - Keep durable state so it can react every time, or handle one matching event and then stop listening.
  That is where the flexibility comes from. Tell Amp how you want to handle an event and it writes the handler that way. It can also call external APIs to post results back to Slack, Linear, GitHub, or wherever the work began. Return to the owning thread whenever you want to change the behavior.
  
  The webhook URL is a credential. Keep it private, and tell Amp to remove it when you no longer need it.
15. 🔗 muffinman SpaceDeck X July devlog: upgrades, backgrounds, and more rss
  
  I've been developing SpaceDeck X since December last year. It started as me playing with a random framework I found fun, and it grew so much that I'm now working towards releasing it on Steam. I kept a devlog on Itch, but I feel like it is time to bring it to my own website. Especially considering that these updates are exclusive to the Steam version.
  
  I have a pretty clear vision for the release, and lately I've made amazing progress. Here are the major things I've made, in no particular order.
  
  Upgrades system
  
  The new upgrades system was brewing in my head for a long time. Honestly, I thought it would take me longer to implement it, but once I started, I got in the zone and built a completely new system.
  
  This is the new upgrades selection screen:
  
  Compare it to the old one:
  
  Upgrades library
  
  Upgrades got their own library, so players can inspect and learn about all of them.
  
  In two days I managed to draw 44 upgrade icons. Some of them I just winged and now I'm retrofitting them to the actual game upgrades.
  
  Redesigned UI panels
  
  After making new upgrade cards, I got an urge to redesign some of the game's UI. I'm trying to avoid scope creep, but I had to create a way for the player to see their upgrades, so I decided to give a facelift to the deck panel as well.
  
  You can open both panels by holding Tab in the boss fight:
  
  And they show automatically in the pause menu:
  
  Ships
  
  Ships are not brand new, but in the last few weeks I tweaked their specific weapons and characteristics. It is still a work in progress, but all ships are functional and have their own quirks.
  
  Backgrounds and shadows
  
  These are purely decorative, but I think they elevate the experience a lot. These background objects add more visual depth. They also change every few levels, giving the player a better sense of progression.
  
  For now I created two sets of backgrounds (the gray tech-industrial one and an Aztec/Protoss-inspired one). The plan is to have four or five for the full game. These are quite time consuming, but I enjoy doing pixel art.
  
  For the gray background set, I drew a tileset and I'm using Tiled to assemble them, while the Aztec ones are all drawn by hand.
  
  Other
  
  Run history is still in progress, but I have the base for the stats screen:
  
  I postponed it for months, and finally I created controller button customization:
  
  See you soon
  
  Ever since I started working on this game, I've been obsessed with game dev. You can probably tell from the fact that I haven't published almost any blog posts this year.
  
  That's why I'll keep these devlogs casual and try to post them more often.
July 22, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-22 rss
  IDA Plugin Updates on 2026-07-22
  
  New Releases:
  - ffxiv_bossmod 7.5.1.29
  - ffxiv_bossmod 7.5.1.28
  Activity:
  - disrobe
    
    cab04b7e: mobile: route arsc and axml chunk reads through the shared bytereader
    
    89e4cc6d: js: route sourcemap data-url decoding through the shared codec percen…
    
    513eb793: php: route urldecode/rawurldecode through the shared codec percent-de…
  - distro
    
    e23820b9: Add container mode to restrict-egress (apply/off/status without systemd)
    
    6d9cc808: Show domain-to-IP mapping in restrict-egress status
  - ffxiv_bossmod
    
    24606cfb: unbreak pot
    
    a1c70605: improve amh araeng
    
    7f2356d5: cdplan conditionals and raw pull protection
  - hrtng
    
    05fccda3: a few fixes:
  - ida-hcli
    
    f8908d1d: Merge pull request #251 from HexRaysSA/fix/bundle-python3-dll-windows
    
    a8cb563f: fix: bundle python3.dll in the Windows binary
    
    2d916e62: fix(asset): strip leading slash from key in asset API paths (#215)
    
    0067acbc: fix: add hcli/main.py so python -m hcli runs the CLI (#226)
    
    5dac83b4: fix: return argv tokens from get_hcli_command (was get_hcli_executabl…
    
    0b5d0cb7: Harden ida:// KE deep-link handler (RCE, path traversal, SSRF, drive-…
    
    679e0f56: fix: ida install -a/-accept-eula flag was inverting, skipping EULA a…
  - project
    
    8cf20019: added statistics
  - quokka
    
    bb8dc9d6: Merge pull request #132 from quarkslab/dm/upgrade-protobuf
    
    6b45902c: Align Python package with protobuf 7.35
  - SignatureGenerator
    
    b7cef659: Add support for IDA 9.4
  - Spectra
    
    dff32c95: Skip exploration for non-analysis tasks
    
    93bb73fa: Skip exploration mode for non-code-analysis tasks
  - twdll
    
    a8460bf3: docs: fix docs building
    
    f5dbd420: build: fix CI submodules init
    
    fbfc3418: chore: add AGENTS.md
    
    24cdb988: feat(wip): add campaign ui and world globals
2. 🔗 Simon Willison OpenAI’s accidental cyberattack against Hugging Face is science fiction that happened rss
  This story is wild. The short version: OpenAI were running a cybersecurity test against an unreleased model, with the model's guardrail features turned off. Rather than solve the test, the model broke its way out of OpenAI's sandbox, then found exploits to break in to Hugging Face, all so it could cheat on the test by stealing the answers.
  
  Along the way it helped make the strongest case yet for how the imbalance of model availability is hurting our ability to secure our software.
  
  Here's what happened
  
  We currently have three documents to help us understand what happened here.
  1. ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks? is a paper published on 11th May 2026 describing ExploitGym, a new eval suite for LLM-powered agent systems.
  2. Security incident disclosure — July 2026 by Hugging Face on 16th July 2026 describes how they detected an attack from an "agentic security-research harness - used LLM still not known" that breached some of their systems.
  3. OpenAI and Hugging Face partner to address security incident during model evaluation from OpenAI on 21st July 2026 confesses that it was their agent harness that did this, and that they're working with Hugging Face to clean up the mess.
  ExploitGym
  
  I hadn't seen the ExploitGym paper before and it's a really interesting one. Authors from UC Berkeley, the Max Planck Institute, UC Santa Barbara, and Arizona State designed a new benchmark for evaluating models on their ability to turn a reported vulnerability into a concrete exploit. OpenAI, Anthropic, and Google provided feedback and helped run the benchmark against their models.
  
  The benchmark "comprises 898 instances derived from real-world vulnerabilities that affected popular software projects" - including the Linux kernel and V8 JavaScript engine. The ExploitGym benchmark is available on GitHub.
  
  Here's the paragraph that best represents their benchmark results:
  
  Among all configurations, Claude Mythos Preview and GPT-5.5 achieve the highest success counts (157 and 120 successes, respectively), demonstrating that current frontier agents can exploit a substantial subset of real-world vulnerabilities under controlled conditions. GPT-5.4 also solves a notable 54 tasks, placing it in an intermediate tier. The remaining model–agent pairings solve fewer than 15 tasks each, underscoring that end-to-end exploitation remains challenging and sharply differentiates today’s frontier systems. Notably, Claude Opus 4.7 achieves fewer successes than Claude Opus 4.6 despite being a newer checkpoint, and does so at substantially lower cost on the full set. Trace inspection reveals that Claude Opus 4.7 and Gemini 3.1 Pro frequently conclude early after judging the target vulnerability non-exploitable.
  
  The paper also describes the approach they took to preventing the agents from cheating by going outside the parameters of the test. This becomes relevant in a moment!
  
  Outbound connections are restricted to a curated allowlist that permits routine package installation (Ubuntu apt repositories and PyPI) and fetching the toolchains required for building V8. All other external endpoints are blocked.
  
  The paper concludes with this (emphasis mine):
  
  Our results show that autonomous exploit development by frontier AI agents is no longer a hypothetical capability. While current agents are not yet reliable across all targets, they already exploit a non-trivial fraction of real-world vulnerabilities, including complex targets such as kernel components. This rapid emergence is itself a central finding, showing that capabilities that would have seemed implausible are now present in deployed frontier models.
  
  An important detail here: this paper isn't about discovering vulnerabilities; it's about being able to take those vulnerabilities and turn them into working exploits.
  
  When Anthropic first restricted access to Mythos back in April they talked about this capability as well. A model that can act on vulnerabilities is a lot more dangerous than one that can just discover them.
  
  One of the ways Fable differs from Mythos is that it's more likely to refuse to weaponize vulnerabilities in this way. I get the impression the US government did not understand that distinction when they banned Fable last month.
  
  The Hugging Face incident
  
  The first hint we got of the attack was in this blog post by Hugging Face on 16th July 2026:
  
  A malicious dataset abused two code-execution paths in our dataset processing (a remote-code dataset loader and a template-injection in a dataset configuration) to run code on a processing worker. From there, the actor escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend.
  
  I hope they release more details about the code that pulled this off. I'm assuming this means packages using the datasets library, a Hugging Face project for bundling up and sharing datasets on their platform. That library used to execute arbitrary code but has been steadily locked down over time, with the 4.0.0 release in July 2025 removing the trust_remote_code=True flag entirely.
  
  Assuming the attack used that library it must have either abused pickle serialization in some way, found some other non-obvious code execution path, or (most likely) specified datasets<4.0.0 as the dependency.
  
  The campaign was run by an autonomous agent framework (appearing to be built on an agentic security-research harness - used LLM still not known) executing many thousands of individual actions across a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services.
  
  This was a sophisticated attack!
  
  Then Hugging Face hit a wall: they tried to use "frontier models behind commercial APIs" - I'm guessing from Anthropic and OpenAI - to help analyze the attack, and were blocked:
  
  When we started the log analysis, we first used frontier models behind commercial APIs. This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker.
  
  They switched to their own self-hosted instance of MIT licensed GLM-5.2 and it helped them figure out what was going on.
  
  This indicated a fundamental asymmetry between the defending team and the (so-far unknown) attacker:
  
  We do not know which model powered the attacker's agents, whether a jailbroken hosted model or an unrestricted open-weight one; either way, the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried.
  
  As a useful indicator of how seriously they took the attack:
  
  [...] Finally, we have also reported this incident to law enforcement agencies.
  
  So who was responsible for this "autonomous agent framework"? It turned out to be OpenAI themselves.
  
  The OpenAI confession
  
  Five days later, on July 21st, OpenAI revealed the culprit. They had been running the ExploitGym benchmark against a new, as-yet undisclosed model, and that model had been operating way outside its intended parameters (emphasis mine):
  
  After investigating, we now know that this particular incident was driven by a combination of OpenAI models — including GPT‑5.6 Sol and an even more capable pre-release model, all with reduced cyber refusals for evaluation purposes — while being internally tested on a benchmark⁠ [ExploitGym] of cyber capabilities. [...]
  
  We estimate maximal cyber capabilities by running this evaluation without production classifiers used to prevent models from pursuing high-risk cyber activity. Our benchmarks run in a highly isolated environment, with network access constrained to the ability to install packages through an internally hosted third-party software that acts as a proxy and cache for package registries.
  
  The models identified and chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production infrastructure to obtain test solutions directly from Hugging Face’s production database. All evidence suggests that the models were hyperfocused on finding a solution for ExploitGym, going to extreme lengths to achieve a rather narrow testing goal.
  
  It's pretty clear what happened here. OpenAI removed safety filters for an in-progress model, locked it up in a sandbox and told it to solve the ExploitGym problems. Given the absence of guardrails there was nothing to prevent the model from attempting to break out of that sandbox, break into Hugging Face, and read the answers from there instead.
  
  OpenAI's sandbox used the now common pattern of allowing access to an allow-list of sites related to installing additional packages via a controlled proxy. In OpenAI's words:
  
  While operating in our sandboxed testing environment, our models spent a substantial amount of inference compute finding a way to obtain open Internet access, in pursuit of solving the evaluation problem. To gain access, the models identified and exploited a zero-day vulnerability (which we’ve now responsibly disclosed to the vendor) in the package registry cache proxy. With this access, our models performed a series of privilege escalation and lateral movement actions in our research testing environment until the models reached a node with Internet access.
  
  So step one was to break out onto the public internet. The model then broke into Hugging Face to find the answers:
  
  After gaining Internet access, the models inferred that Hugging Face potentially hosted models, datasets and solutions for ExploitGym. Knowing this, the model searched for and successfully found ways to gain access to secret information that it could use to cheat the evaluation. In one example, the model chained together multiple attack vectors, including using stolen credentials and zero-day vulnerabilities to find a remote code execution path on the Hugging Face servers.
  
  Chaining together multiple attack vectors is exactly the kind of thing these new models can do, where previous generations of models might have failed.
  
  I wrote last month about how Claude Fable is relentlessly proactive, when I noticed it spinning up custom web servers and deploying CORS tricks on my own laptop just to help debug a WebKit CSS issue. It turns out relentless proactivity is the defining trait of this new generation of Mythos-class models. If you set them a goal and give them a way to get there, even inadvertently, they will figure it out.
  
  Resist the temptation to write this off as a stunt
  
  There will inevitably be some people who dismiss this story as a dishonest marketing trick by OpenAI to make their models sound terrifyingly effective. I found 81 instances of the term "marketing" in the Hacker News discussion of the incident.
  
  To those people I say pull your heads out of the sand - you're now including Hugging Face in your conspiracy theories, just so you can deny the crescendo of evidence here!
  
  The best models we have today have the ability to both find and exploit new vulnerabilities. The ExploitGym paper itself concludes that "autonomous exploit development by frontier AI agents is no longer a hypothetical capability", and this incident is a perfect example of exactly that.
  
  The asymmetry is increasingly frustrating
  
  One of the most infuriating details of this story is how Hugging Face, faced with an accidental and aggressive attack from one of OpenAI's models, were unable to then turn to OpenAI's models to help them fend off the attack.
  
  The frontier models we have access to are increasingly being constrained in how much they can help us protect our software, heavily influenced by the US government's ongoing threat of export controls. Claude Fable 5 wouldn't even proofread this article for me! It insisted on downgrading me to a less capable model.
  
  Meanwhile open weight models from China such as GLM-5.2, Kimi 3 and the new Qwen 3.8 Max appear to have none of these restrictions - and any restrictions that do exist can likely be fine-tuned out of them by modifying the weights
  
  These constraints are meant to make us safer. I think there's a risk that they are having the opposite effect.
  
  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.
3. 🔗 HexRaysSA/plugin-repository commits sync repo: +2 releases rss
```
sync repo: +2 releases

## New releases
- [SigMaker](https://github.com/mahmoudimus/ida-sigmaker): 1.14.2, 1.14.1
```
4. 🔗 toon-format/toon v4.0.0 release
  🚨 Breaking Changes
  - Remove key folding and path expansion - by @johannschopplich (46956)
  🚀 Features
  - Decode-side comment lines with encoder quoting of #-leading strings - by @johannschopplich (13561)
  - Nested field groups in tabular headers - by @johannschopplich (128fc)
  - Keyed tabular form for objects of uniform objects - by @johannschopplich (68464)
  - decode : Reject indentation depth jumps in strict mode - by @johannschopplich (6db88)
  🐞 Bug Fixes
  - decode :
    
    Prevent false array header detection for unquoted keys c… - by @rayriffy in #314 (13360)
    
    Trim value tokens by U+0020 only - by @johannschopplich (fea26)
    
    Reject over-indented orphan lines and trailing root content in strict mode - by @johannschopplich (4489d)
    
    Treat a trailing carriage return as part of the line terminator - by @johannschopplich (9562c)
    
    Reject keyless headers outside root and list-item positions - by @johannschopplich (1560d)
    
    Reject inline content after fields-bearing headers - by @johannschopplich (06bd0)
  - encode :
    
    Quote leading-plus numeric-like strings - by @johannschopplich (b769d)
  View changes on GitHub
5. 🔗 BarutSRB/OmniWM OmniWM v0.5.8 release
  What's New Since 0.5.7
  
  Appearance and Layout
  - Added system-wide window corner controls under Settings → General → Appearance on macOS 26.4 or later. Choose the macOS default, square corners, or a custom radius; affected apps must be fully quit and reopened. OmniWM’s focus border now follows each window’s actual corner geometry.
  - Added per-display inner-gap overrides alongside the existing outer-margin overrides. Display IPC and CLI queries now report resolved inner and outer gaps with cleaner whole-number formatting.
  - Fixed Dwindle interactive resizing so minimum-size limits use the active display’s resolved inner gap.
  Focus and Gestures
  - Trackpad column scrolling now focuses the snapped landing window after a completed gesture, while cancelled or interrupted gestures leave focus unchanged.
  - Trackpad gestures now recover automatically after sleep or wake, unlock, and trackpad connection or removal.
  - Follow Window to Monitor now also applies when moving windows up or down between workspaces and when moving columns to numbered or adjacent workspaces.
  - Cross-workspace window selection, including Focus Previous Window and Workspace Bar navigation, now completes focus reliably after relayout without overriding a newer focus action or issuing duplicate transitions.
  Reliability and Fixes
  - Closing a Niri column now clamps the viewport to the remaining content, preserving its centering policy and preventing dead space or partially off-screen windows.
  - Further hardened the window-reliability work from 0.5.7: delayed Accessibility callbacks, retries, rescans, and frame writes are now tied to the exact current window so stale work cannot affect its replacement.
  - Fixed Workspace Bar clicks for workspaces whose names contain emoji.
  Project
  - Refreshed contributor and sponsor acknowledgements and documented how to capture trace files for bug reports.
  Release Integrity
  - OmniWM-v0.5.8.zip contains the Developer ID signed, notarized, and stapled OmniWM app.
  - OmniWM-v0.5.8.zip SHA-256: e61337daace74a8741cc001a0c874bc45d95e0219c415fd3fae8f5833e670f9b
  - GhosttyKit.xcframework-v0.5.8.zip SHA-256: 557f08c7f89467d1f28a2caa734216ade8673ba1ecfa27802c276975c0a53ac5
6. 🔗 r/reverseengineering 10 Years of Binary Ninja rss
  
  submitted by /u/Psifertex
  [link] [comments]
7. 🔗 @binaryninja@infosec.exchange Current Binary Ninja newsletter subscribers are automatically entered. New mastodon
  
  Current Binary Ninja newsletter subscribers are automatically entered. New subscribers who sign up during the giveaway will also be entered for remaining drawings. Sign up here:https://v35.us/dn6rcg5
8. 🔗 @binaryninja@infosec.exchange Discount valid for up to one year of support renewal and new purchases. We mastodon
  
  Discount valid for up to one year of support renewal and new purchases. We love our existing customers and our new ones!
9. 🔗 @binaryninja@infosec.exchange Celebrate 10 years of Binary Ninja! For the first time ever, we’re offering a mastodon
  
  Celebrate 10 years of Binary Ninja! For the first time ever, we’re offering a 35% discount! Join us for 10 full days of giveaways including licenses, merch, and more. Huge shoutout to everyone who has been with us since the beginning, and here’s to everything still to come. Join in on the celebration: https://binary.ninja/10years
10. 🔗 r/reverseengineering Great introduction to ARM using pwnable challenge rss
  
  submitted by /u/AdvisorPowerful9769
  [link] [comments]
11. 🔗 r/reverseengineering Hey everyone, I wasn’t a fan of the official software for the ChargerLab POWER-Z KM003C, so I decided to reverse-engineer the USB interface and build my own open-source terminal tool: VoltReaver. rss
  
  submitted by /u/dan89156108
  [link] [comments]
12. 🔗 pydantic/pydantic-ai-harness v0.9.0 (2026-07-21) release
  What's Changed
  
  Important
  
  This release raises the pydantic-ai-slim floor to 2.14.1.
  - feat(cache_stability): observational CacheStabilityMonitor capability by @dsfaccini in #327
  - feat: web_search text_summary mode and deferred ExaAgent capability by @ryahern in #386
  - Fix ClearToolResults corrupting typed ToolReturnPart subclasses (ToolSearchReturnPart) by @dsfaccini in #383
  - Bump pydantic-ai to 2.14.1, migrate durable tests to the durability capabilities, raise the floor by @adtyavrdhn in #397
  New Contributors
  - @ryahern made their first contribution in #386
  Full Changelog : v0.8.0...v0.9.0
13. 🔗 r/reverseengineering GitHub - NtProtectVirtualMemory/PE-Library: A modern C++ library for parsing and manipulating Windows Portable Executable (PE) files. rss
  
  submitted by /u/Effective-Fly7516
  [link] [comments]
14. 🔗 Mitchell Hashimoto Everyone Should Know SIMD rss
  
  (empty)
15. 🔗 exe.dev Run a Slack Bot from Your VM (Without Giving It the Keys) rss
  You can now interact with your VM on Slack. We store your Slack credentials outside your VM so you don’t have to worry about agents running amok (incidentally, that’s true of all our integrations). There are two flavors of Slack integration:
  
  Slack
  
  The first is a send-only version of Slack (just labelled “Slack” on the integrations page). You can read more about it here: https://exe.dev/docs/integrations-slack
  
  Hooking it up is simple. When you create an integration, you will be directed to Slack to choose a workspace and channel. Then, attach the integration to a VM and call it from there:
```
curl --json '{"text":"Everything is groovy"}' https://<slack-integration-name>.int.exe.xyz/
```
  Your message will show up in the linked channel.
  
  Slack Bot
  
  The second flavor is a little more complex, but much more flexible. It’s called “Slack Bot” on the integrations page. It will allow you to make a fully fledged Slack bot that can read/write and do whatever else you give it permissions to do. The setup is a little more involved because you need to make the app and grant it all the permissions you want your bot to have. More detailed instructions are on the documentation page: https://exe.dev/docs/integrations-slack-bot
  
  Once you’ve created your app, drop its two tokens into the integration. Then you can do a simple curl call to write to the channel:
```
curl -X POST https://<slackbot-integration-name>.int.exe.xyz/api/chat.postMessage --json '{"channel": "#exe-dev-integration-test","text":"hi"}'
```
  Or you can make a full-blown responsive chatbot. There’s demo code included in the documentation.
  
  Have fun and enjoy slacking!
16. 🔗 Ampcode News Multiplayer rss
  
  Three weeks ago, we shipped agents in orbs.
  
  Today, more and more of our work happens inside orbs. In fact, the orbs are quickly becoming the de facto "unit of work." They contain not just the code of the solution, but also the description of the problem, and often they are the running, executing solution itself. The lines between description, solution, code, and computation are all blurring and merging into the orb.
  
  As more of our work moves into orbs, we need better ways to share, control, and collaborate on those orbs and the artifacts they create.
  
  Multiplayer now lets you do just that.
  
  Turn any of your orbs into a multiplayer environment from the thread's Share menu.
  
  Anyone in your workspace can then join the thread, send messages to the agent, and access the orb's portal, file changes, and shared terminal until multiplayer mode expires.
July 21, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-21 rss
  IDA Plugin Updates on 2026-07-21
  
  New Releases:
  Activity:
  - disrobe
    
    ed5cc682: dotnet: profile CIL handler ABI
    
    eba3dc49: vulnmatch: add indirect reachability soundness
    
    f3fb3472: dotnet: lower profiled CIL handler effects
    
    d88cfa14: vulnmatch: add reachability matching
    
    5aa3b6d3: vulnmatch: scaffold the reachability-aware vulnerability matching crate
    
    b1d01316: dotnet: structure devirtualized control flow
    
    69ffbfa2: native: add a64 predicate lifter
    
    1aa4a0fc: dotnet: emit recovered devirtualizer ir
    
    1349699e: native: add aarch64 decoder
    
    6a117f54: dotnet: add bounded devirtualization core
    
    abbaf38e: nir-lift: resolve wasm branch targets through a depth-indexed map bui…
    
    74783030: swift-objc: charge each substitution-repeat clone against the node bu…
    
    549b2b17: pickle: refresh memoized-container snapshots lazily at get, embed, an…
    
    3bff2feb: py-decompile: cap unpack-sequence element prealloc to the op window a…
  - distro
    
    b21153d9: Add restrict-egress script to limit outbound access to an allowlist
  - ffxiv_bossmod
    
    ea51dc24: support conditional cdplan tracks
    
    d7e78a29: thin ice
    
    4503f198: fix rect bounds bitmap offset
    
    06fdcb96: fix mare map
  - ida-llm-explainer
    
    dd88a7b7: Fix: named .bss globals dropped by is_loaded gate in resolve_global_q…
    
    de394589: v1.9.0: compiler-verified C export + open in Compiler Explorer
  - ida-sigmaker
    
    ea522494: Merge pull request #91 from mahmoudimus/diff/fix-release-workflow
    
    14220b5f: Fix automatic PyPI release workflow
    
    3e4652fe: Prepare 1.14.2 release metadata
    
    4e42b229: Merge pull request #90 from mahmoudimus/diff/raise-pure-python-coverage
    
    6dd2fc3e: Authenticate coverage upload with GitHub OIDC
    
    f4c79246: Bound CI coverage resource usage
    
    551f8108: Prepare 1.14.1 release and publish coverage
    
    d90737e3: Raise CI coverage gate to 90 percent
    
    f5cb017a: Raise coverage above 95 percent
    
    2d2a41d1: Cover short unique generator candidates
    
    a256a95a: Fix signature defaults and SIMD debug logging
    
    b62a43e8: Add real-binary minimal generator fixture
    
    1dcfe01e: Raise pure-Python coverage above 90 percent
    
    a75f2b7d: Merge pull request #89 from mahmoudimus/diff/fix-coverage-collector
    
    eebfb278: Fix CI coverage collection
  - IDA-VTable-Utility
    
    ae034f05: Track aliased VTable calls
  - IDAPluginList
    
    b4276abe: chore: Auto update IDA plugins (Updated: 19, Cloned: 0, Failed: 0)
  - Luc-Nhan
    
    0cafac58: chore(release): bump version to 1.13.3
    
    ea70bd97: Merge branch 'fix/ui-a11y-contrast-shortcuts': UI/UX accessibility fixes
    
    f9dbbe6e: fix(ui): improve accessibility — contrast, shortcuts, tooltips, labels
  - quokka
    
    d029a4fc: Merge pull request #131 from quarkslab/dependabot/github_actions/acti…
2. 🔗 earendil-works/pi v0.81.1 release
  New Features
  - Verifiable release source archives — GitHub releases now include deterministic, checksummed source archives with instructions for rebuilding standalone binaries. See Building standalone binaries from release source.
  - Resilient compaction and branch summaries — Transient provider failures now follow the configured retry policy, with retry lifecycle events available to interactive, JSON, RPC, and SDK consumers. See Compaction & Branch Summarization and RPC retry events.
  Added
  - Added deterministic, checksummed source archives to GitHub releases with documented standalone binary rebuild instructions (#6913 by @christianklotz).
  Fixed
  - Fixed compaction and branch summarization to retry transient provider failures using the configured retry policy, with retry lifecycle events exposed to interactive, JSON, RPC, and SDK consumers (#6901 by @davidbrai).
  - Fixed interactive startup waiting for background model catalog refresh while computing the footer provider count.
  - Restored the default stream fallback for extensions using the pre-0.81 agent-core API (#6915).
  - Fixed inherited Kimi K3 models from Moonshot AI and Moonshot AI China to use the OpenAI thinking format and expose reasoning effort support.
3. 🔗 @binaryninja@infosec.exchange Big news, coming soon! mastodon
  
  Big news, coming soon!
  
  https://binary.ninja/10years/
4. 🔗 earendil-works/pi v0.81.0 release
  New Features
  - Local llama.cpp model management — Connect to a llama.cpp router, search and download Hugging Face models, and explicitly load or unload models with live progress. See llama.cpp.
  - Full provider extensions — Extensions can register complete pi-ai providers with authentication, model refresh, filtering, and custom streaming. See Register New Provider.
  - Qwen Token Plan providers — Use the built-in international and China subscription providers with regional endpoints and API-key authentication. See API Keys.
  - Expanded usage accounting — Tool, compaction, and branch-summary usage is persisted and included in session totals. See Compaction & Branch Summarization.
  Added
  - Added Qwen Token Plan and Qwen Token Plan China to built-in provider setup, default model resolution, and provider documentation (#6858 by @QuintinShaw).
  - Added the get_available_thinking_levels RPC command and RpcClient.getAvailableThinkingLevels() method (#6865 by @cristinaponcela).
  - Exported message and tool execution lifecycle event types from the package root (#6772 by @davidbrai).
  - Added built-in llama.cpp router support with /login connection setup and /llama Hugging Face model search and downloads, explicit loading, unloading, and live progress. See llama.cpp.
  - Added extension registration for complete pi-ai providers, including native authentication, model refresh, filtering, and streaming behavior.
  - Added usage accounting for tools, compaction, and branch summaries in persisted sessions, footer totals, and session statistics (#6671 by @davidbrai).
  Fixed
  - Updated the packaged brace-expansion dependency to 5.0.7 (#6896 by @davidbrai).
  - Fixed persisted remote model catalogs from overriding newer bundled catalogs after an upgrade.
  - Fixed inherited stored API-key credentials to apply their provider-scoped env values, including Amazon Bedrock profiles (#6864 by @cristinaponcela).
  - Fixed inherited OpenAI-compatible cross-provider replay to keep tool call IDs unique when multiple calls share a provider call ID (#6854 by @cristinaponcela).
  - Fixed inherited Kimi K3 thinking levels to expose low, high, and max, and normalized the k2p7 alias to kimi-for-coding.
  - Fixed inherited OpenCode Go models routed through the OpenAI Responses API.
  - Fixed inherited pi-ai package metadata to avoid repeated consumer lockfile changes (#6812 by @jmfederico).
  - Fixed inherited terminal shutdown to clear the editor's inverted software cursor before restoring the hardware cursor (#6790 by @dam9000).
  - Fixed inherited ANSI-aware text wrapping to recognize CRLF and CR line endings while preserving styles (#6764 by @xz-dev).
  - Fixed inherited editor paste registry corruption after deleting and undoing paste markers, preventing literal or mismatched paste markers in submitted prompts (#6844).
  - Fixed sessionless OpenAI Codex WebSocket requests to use UUIDv7 request IDs (#6834 by @xl0).
  - Fixed inherited GPT-5.6 Codex models to default to the 272K context window, avoiding automatic long-context pricing (#6853 by @aadishv).
  - Fixed messages queued during compaction to preserve steering and follow-up delivery behavior (#6730 by @dannote).
  - Fixed read tool errors being syntax-highlighted as if they were file contents (#6731 by @dannote).
  - Fixed llama.cpp router download progress updates and removed redundant wording from model action confirmations.
  - Moved automatic model catalog network refresh out of startup initialization and into the running interactive and RPC modes.
  - Fixed persisted sessions being read and parsed twice when opened, reducing startup latency for large sessions (#6793).
  - Fixed prompt-template defaults for all arguments (${@:-default} and ${ARGUMENTS:-default}) (#6695).
  - Fixed obsolete custom UI, custom tool, and custom editor examples in the extension documentation (#6735).
  - Fixed Kimi Coding sessions to show API-equivalent implied costs with the subscription indicator.
  - Fixed OpenAI Responses early stream endings to trigger automatic retry instead of ending the agent run (#6727).
5. 🔗 Simon Willison A Fireside Chat with Cat and Thariq from the Claude Code team rss
  Earlier this month I hosted a fireside chat session at the AI Engineer World's Fair with Cat Wu and Thariq Shihipar from Anthropic's Claude Code team. We talked about Claude Code, Claude Tag, Fable, coding agent security, evals, tool design, and how Anthropic use these tools themselves.
  
  The full video of the session is now available on YouTube. Below is an edited copy of the transcript, with extra links and my own bolded highlights.
  
  A few top-level notes if you don't want to watch the video or wade through the whole transcript:
  - Claude Tag (Claude's new collaborative Slack integration) now lands 65% of the product engineering PRs for the Claude Code team.
  - Claude Code ships features to Anthropic employees first, and only ships the features that demonstrate user retention with that cohort
  - Critical changes to Claude Code are still reviewed manually, but the team increasingly relies on automated code review for the "outer layers" of the product.
  - Adding examples to a system prompt is no longer best practice for models like Fable 5 or even Opus 4.8. The Claude Code system prompt recently reduced in size by 80%.
  - Likewise, lists of "don't do X and don't do Y" can reduce the quality of results from the latest models.
  - Dogfooding inside Anthropic is called "ant fooding".
  - Anthropic really believe in their auto mode, and see that as an enabling technology for Claude Tag.
  - Thariq advises offsetting coding-agent-induced Deep Blue by "being more ambitious" with the work you take on.
  - Fable is competent at editing video, and Thariq used it to edit its own launch video.
  - Anthropic's culture of working (internally) in public is key to their success, as demonstrated by the way they use Claude Tag in their public Slack Channels.
  How has what you do day-to-day changed in the past year?
  
  1:05
  
  Simon: Claude Code came out in February of last year — it's under a year and a half old, and it was originally just a bullet point on the Claude Sonnet 3.7 launch. How has what you do on a day-to-day basis changed in the past year, now that we have these coding agents that actually work for us?
  
  Cat: I remember when we first came out with Claude Code and Sonnet 3.7, you would give it a task and you would have to closely monitor every single little thing it tried to do. I would read every permission prompt extremely carefully. I would frequently say no — no, no, no, did you check this file? Did you check that file? And now it's been incredible with every model generation. I feel like we've all gotten a chance to take a step back and delegate a lot more of the menial implementation to Claude. It's freed up a lot of our time to think about more creative work, like: what is the right experience that we should be providing to our users, now that we know Claude Code can implement a lot of it? And now with Fable it's a totally different step change improvement. We see for a lot of our use cases that you can actually one-shot a ton of features with Fable now.
  
  Thariq: I remember the first text I got about Claude Code. One of my best friends was like, "You need to go try Claude Code." It was about when Opus 4 came out, and I tried it and I was like, "Oh, shit. I need to work at Anthropic now." And that was Opus 4 — great model, but you were reading permission prompts. It's kind of crazy how much amnesia we have, where I'm like, oh, auto mode has always been here, right? I don't even remember pressing yes and allow. For me, the big thing I'm trying to push myself on is that we have to do higher quality work than we've ever done before. The outputs are incredibly high quality. I've been using it to edit videos a bunch, and I'm like, okay, it has to meet the very exacting demands of our brand team in a couple of hours or we just can't do it. That's how I'm trying to shift with Fable: the best work we've ever done, faster than we've ever done it before.
  
  What piece of conventional software engineering no longer holds?
  
  3:39
  
  Simon: What's a piece of conventional software engineering that was true a year ago that you don't think holds anymore in this new world?
  
  Cat: One of the biggest shifts we're seeing in the eng skill set: two years ago it was pretty typical for a product manager to go talk to a bunch of customers, align over the course of six months with cross-functional teams on some PRD, and write a thorough spec on exactly how we'll implement this before the first line of code gets written. Now things are completely turned the opposite way. For a lot of engineers, the push I would give to folks in the room is to develop more of your business sense and product sense on what it is we should build, because the timeline between having an idea and building it is so much shorter — it's down from six to twelve months to maybe even a week. That means all of us need to have better taste on what is worth building, what will actually inflect the businesses we're working on. So it's an increase in value on product taste and business sense, and a bit lower on execution in most product domains. Of course, for infra there's still a very heavy emphasis on making sure all the details are right.
  
  Thariq: For me, it's that rewrites are now good.
  
  Simon: The worst thing you could do is now actually fine!
  
  Thariq: Exactly. All the Mythical Man-Month stuff — never rewrite — I'm pro-rewriting now. If you have a good test suite — and I think the rewrite actually forces you to make sure you have a good test suite — but I think what people undercount is that a codebase is a spec, and maybe it's the only copy of the spec that you have, because no one knows every branching part of the codebase. You can take this as an artifact and distill it or create other versions of it. We rewrote Bun in Rust and it works great — it's live for me right now.
  
  Simon: You're not shipping Claude Code on Bun-in-Rust yet, right?
  
  Thariq: Internally we have.
  
  (Actually it looks like Anthropic started shipping Claude Code on Bun-in-Rust to everyone on June 17th.)
  
  What kind of things are non-engineers doing with Claude Tag?
  
  6:36
  
  Simon: The other big launch recently was Claude Tag — that's what, a week old now, at least for the rest of us. I understand it's being used at Anthropic by non-engineers a great deal. What kind of things are non-engineers doing with Claude Tag?
  
  Cat: Claude Tag is a Claude that lives in your team's collaboration tools. We launched it last week within Slack. The thing that's different about Claude Tag is it's multiplayer by default. Once you add Claude Tag to a Slack channel, you can chime in, your teammates can chime in, and you can collaborate together on the PR. The other big difference is that it's proactive instead of reactive. You can tell Claude Tag, "Hey, monitor every bug report in this channel, put up a PR to fix it, and tag the engineer who last touched this part of the codebase," and it'll do it for the lifetime of the channel without you having to manually tag it in. And the third big shift is that we've added team memory into this. If you tell Claude Tag your preferences in the channel, it'll remember them for every future post. If you always want it to debug outages but you don't want it to debug warnings, just tell it that in natural language in the channel and it'll remember it for you and everyone else on your team.
  
  Internally, we see Claude Tag as the evolution of Claude Code. We see this as a large shift in how we work internally. Claude Tag currently lands 65% of our product eng PRs.
  
  Simon: For all of Anthropic, or just for Claude Code?
  
  Cat: This is just for our product engineering team — our internal version of Claude Tag lands 65% of our product PRs right now. And this is a huge shift; this is more than 50% of our PRs. The way we see people split work between Claude Code and Claude Tag is: Claude Code is still the best place for your most complex tasks, when you're interactively iterating with the agent. But Claude Tag is great for having it work proactively on your behalf, so you no longer need to manually kick off Claude Code for all the bug reports that come up for features you're working on.
  
  Thariq: And for non-coding cases: for example, before this talk we asked Claude Tag, "Hey, when is Fable releasing?" We wanted to make sure we'd line it up with the announcement. Claude Tag would search our Slack and look at who's been saying what. As a search engine for your company, it's really valuable. It has all the context for your product, so you can ask it metrics-related questions — often when you're making decisions you want them informed by what the metrics say, so you hook it up to your event store. I've seen our marketing team do things like, "Hey, tell me about this feature." They're not programmers, but Claude is a programmer — it can clone the codebase and say, "This is the feature, this is what it looks like, this is a recording of me using the feature." It enables a whole wide variety of things, and I think we're still early in figuring that out.
  
  Claude Tag as the team collaborative layer
  
  10:06
  
  Simon: One of the problems I've had with coding agents is that I get how to use them as an individual, but I'm not really clear on how to use them in a team environment. It sounds like Claude Tag is your current answer to that team collaborative layer for this stuff.
  
  Cat: Exactly. And a large percentage of our sessions are actually multiplayer right now. Maybe I say, "Hey, I think we should implement this new feature in Cowork," and I'll tag in Claude Tag to do a first pass at it. Then I'll tell Claude Tag, "Share a recording of your final implementation," and I'll tag in design to take a look. They'll nudge it, then pass it on to eng to take it to the finish line and get it out to prod. It's been this very fluid experience. We're still trying to iron out what the social dynamics are for steering the same session, but we've found that people just observe how others use it and follow those social norms — it's been pretty intuitive for us to integrate Claude Tag into our teams.
  
  Thariq: It's great for teaching people, and also for reducing slop, because the fact that everyone is seeing you use Claude together sort of levels up how you use Claude as well.
  
  This reminded me of how Midjourney solved the challenge of teaching people advanced image prompting by enforcing prompting in public in their Discord channels.
  
  How do you decide which features are worth building when building is so much cheaper?
  
  11:41
  
  Something I've found really hard myself is knowing when a feature is worth shipping now that the cost of actually building features has dropped so much.
  
  Simon: How do you deal with the hardest problem in all of engineering — prioritization? How do you decide which features are worth building and shipping when building a feature is so much more inexpensive now?
  
  Cat: This is the hard thing. There are a few ways we approach it. One is we dogfood our products every single day. Whenever there's something we want to be able to do in our products that we're not able to, instead of finding a different solution we fix our product so it can support that case. We have a very heavy dogfooding culture internally. Before we share our products with everyone in the world, we share them with everyone within Anthropic, and with some early customers who give us very honest feedback about it — the more brutal the better — and we iterate until people love it. We have an internal bar for the number of active users and the amount of retention a feature has to have before we share it with the world. Because this bar is very clear, every engineer knows what they're trying to hit. I think this also levels up our polish, because if the feature isn't polished, people will churn — and then we shouldn't ship that feature.
  
  Using internal user-retention to decide if a feature should ship makes a whole lot of sense to me.
  
  Do you have an example of a feature which surprised you?
  
  12:54
  
  Simon: Do you have an example of a feature which surprised you? You rolled it out and the engagement was off the charts — something unlikely to be shipped that turned into a real product thing.
  
  Cat: I do have one. A lot of folks on our team love remote control. Remote control lets you use your mobile device, or Claude in the web browser, to connect to a local Claude Code session running in your CLI. I never have this need, because I just kick off the task directly on mobile and it runs in a cloud session without using my local environment — I think because I'm doing very easy coding tasks. It was something I didn't totally understand; I was like, hey, people should just set up remote dev environments. But in practice, once we rolled out remote control, so many people I talk to told me that what they do every night is plug their laptop into a power charger, open a bunch of remote control sessions, lock the screen, and then use their mobile phone from their couch to control Claude Code. So this has become a flow we're now leaning into that I didn't originally get — but now I do.
  
  Does a human review every line of production code in Claude Code?
  
  14:20
  
  One of the over-arching themes of the conference was review: how much attention to people spend to reviewing code written for them by coding agents. I was very keen to hear the Claude Code team's take on this!
  
  Simon: How does code review work? Does a human being review every line of production code that makes it into Claude Code? And if not, what are you doing — how do you keep the quality up?
  
  Thariq: It varies on the task a lot. For important areas we have code owners. The system prompt is an example where we have a code owner — you really need to get their approval.
  
  Simon: So the code owner is directly responsible for the quality of that area of the code.
  
  Thariq: That's right.
  
  Cat: And they need to approve any PR that touches it.
  
  Thariq: We have our code review GitHub bot review everything — that goes on every PR, and often it's doing the bulk of the review. Something I've seen on the team is that for more complex PRs you might make an artifact to explain the PR so that other people can then review. And we invest a lot into verification, CI/CD, things like that, to make sure that any time anything fails we have a test. We have a really robust environment where Claude can control Claude Code and test it. So there's a multi-pronged approach to code review.
  
  Cat: In general, we are trying to move to a world where humans don't need to be in the loop. For the most critical changes to the core of Claude Code, and the cores of other products, there is always a code owner and they do manually review all the changes. But increasingly, for the changes at the outer layers, we actually have Claude code review fully review those. That sounds pretty scary, but we've had a six-plus-month-long process to get here, and there are baby steps that you take to build up trust with code review. In the beginning we had human review for everything, and then increasingly we would say, okay, for code changes that touch these files, code review is catching 100% of the issues there — so we actually don't need a human manually reviewing those. And when we have incident review, we look at the PRs that caused the incident and say, okay, how do we update code review to catch that? — and we take those PRs and add them to an eval set to make sure our future changes to code review never regress that metric. Removing humans from the code review loop is a big step forward. It can sound scary, and it's not something you can do overnight, but it is something you can do through many months of investment in the infrastructure to give you the confidence that code review is catching everything you care about.
  
  So the key seems to be constantly iterating on the automated review systems themselves, in order to build trust in them over time.
  
  How does a new model affect your intuition for what it can and can't do?
  
  17:20
  
  We got deep into evals - another hot topic throughout the wider conference.
  
  Simon: I know that Opus 4.8, if I ask it to build me a JSON endpoint that runs a SQL query and outputs JSON, is just going to get it right — that's not something I have to review closely. But then a new model comes along and I don't know how to build trust in Fable quickly, that it's not going to mess things up that Opus didn't. How does the new model affect your intuition for what it can do and what it can't do?
  
  Cat: The main reason we're building up this eval base over time is so that new models can be a drop-in replacement. When we have a new model, we run the whole eval set and make sure that, for example, Fable is strictly better than Opus 4.8 — and that gives us the confidence to drop it in.
  
  Simon: Are those model evals for Anthropic as a whole, or Claude Code team-specific?
  
  Cat: We have both. We have evals on our team, and we run code review across every repo within Anthropic, so we have evals for that. And for things like auto mode, we not only have evals across every user within Anthropic — we've also commissioned multiple external testers to red team it, to create environments with prompt injections and malicious inputs, and make sure that auto mode doesn't let any of those pass.
  
  How do you build confidence that a system prompt tweak results in better output?
  
  18:41
  
  Simon: I want to know if the system prompt improvement I made actually improved the product — that's the most basic form of product-specific eval, and I still don't have a great feel for how to do that. Is that something you're doing such that you have complete confidence that a tweak you've made to the system prompt results in better output?
  
  Cat: We don't have complete confidence, but we do a lot to make sure that we don't regress performance. The starting point is a suite of external evals that we trust, and we complement that with an even larger suite of internal evals that we trust. To start, we mainly optimize for capability: given a complete definition of a task and the full codebase, does Claude make the right decisions, fully fix the bugs, and pass all the tests? That's the starting point and the thing we optimize for, because it's most directly what users want. But there are a lot of behaviors that impact how users feel when they work with Claude Code. For example, people really don't like it when Claude Code says it's time to go to sleep. Or people really don't like it when it says, "Hey, I finished two out of five parts — do you want me to continue?" Yes, please continue. So we're building up a set of behavioral evals to catch these. And as we get user feedback — please be loud with us about your user feedback — we rank the priority issues and go down one by one and build evals for each of them. It's not 100% coverage, but it is a priority for us to increase the coverage.
  
  How much interaction is there between the Claude Code team and the model training teams?
  
  20:21
  
  Simon: How much interaction is there between the Claude Code team and the teams at Anthropic who are training the models in the first place? Is that quite a close collaboration?
  
  Cat: Across Anthropic, we all work quite closely together. We meet often to talk about what we expect the next generation of models to be able to do. Our research team has also been amazing about showing this publicly — we often talk in our blog posts about how we're targeting ever-increasing longer-horizon work, and how we train Claude itself to be honest, harmless, and helpful. We also put a lot of effort into making sure it's aligned with your intent, even if your intent is expressed in a fuzzy way. Of course, try your best to be specific about what you want, so Claude has all the context — but even when you're not specific, we teach Claude to make good assumptions. It's been a productive partnership.
  
  The system prompt has been reduced by 80% — what have you been able to drop?
  
  21:24
  
  So many useful prompting tips in this section!
  
  Simon: Thariq, you mentioned this morning that the system prompt for Claude Code has been reduced by 80% because of Claude Fable. Can you go into a little more detail? What kind of things have you been able to drop?
  
  Thariq: It wasn't just Fable — it was Opus 4.8 as well, and going forward, future models. We have different system prompts for different models now. One of the patterns we saw is that we were over-constraining Claude. The initial, maybe Opus 4-ish models wanted a lot of examples, and removing examples was extremely helpful, because it was just more creative than the examples we gave it.
  
  Simon: That's really interesting, because one of the top prompting tips I give people is: give it examples. If that's no longer true, that kind of breaks my prompting model a little bit.
  
  Thariq: Same here — I was surprised to hear that. I think now it's more about the shape of what you give it — the tools you give to Claude, your system prompt, things like that. The other thing we did is try to give it more context and fewer "do not do this" instructions, because that's a very strong impulse for Claude, and especially if it conflicts with user instructions later on, that can be extremely confusing to Claude — "I've got this skill that says this and the system prompt says this." So we try to have fewer hard constraints, more context, and fewer instructions overall. It's definitely a science — it took a bunch of evals to build.
  
  Cat: In general, when you're prompting these models, you should always think: are there edge cases to the instruction that I'm giving it? When we went back and reviewed all the instructions in the Claude Code system prompt, we found a few cases where yes, this statement is 90% true, but there's a real 10% of cases where it's not true. We didn't want to constrain the model, or confuse it into thinking it should always do this. One good example is verification. Everyone here wants Claude to verify its work, and we had some instructions in the prompt that said: if you make a front-end change, always verify. But there's a limit to it. If it's changing copy from one string to another string, and the user says "just make a quick fix and update the test," maybe you don't want to verify. So we've adjusted our wording from "always verify, verify, verify" to something like: most of the time when you're doing front-end work you can't fully understand the experience by hitting the backend endpoints, so when you make larger changes to the user experience, please run the app locally. And in fact, that instruction probably isn't even good either, because what is a large change? Maybe it should test small changes too. In general, whenever you give a prompt to the model, you should think about the ways in which it could be misinterpreted by a well-intentioned human, in order to better understand how the model might interpret it — and soften the prompt so that it's actually 100% accurate, because you're giving this prompt to the model 100% of the time.
  
  Simon: What's fascinating about that is you're relying on the model's judgment — and that's got to be an Opus/Fable-level thing. Models a year ago did not have the level of judgment necessary to decide whether they were going to test a change or not. But that does break down if you're building for a wide range of models and trying to run the cheaper models for cheaper tasks.
  
  Cat: We actually have a different system prompt per model now, for this very reason. It's only our most frontier models that have this 80% token decrease — the older models still have the full system prompt.
  
  Simon: Do you think Fable and Opus are smart enough to prompt Haiku with more details, because they understand that Haiku has less judgment, less taste?
  
  Cat: We haven't been able to eval it — we don't have any hard data to show it.
  
  Thariq: There's a tough thing with smaller models sometimes, because sometimes the larger models can be more token-efficient on a hard problem than the smaller models. So there's a bit of intuition to build there — sometimes you really just want frontier intelligence almost all the time. The Pareto curve shifts, and it's hard to find.
  
  Simon: A year ago I did not trust a model to write a prompt. Today the good models are very good at prompting — a lot of my prompts are written by models, which feels absurd but works really well. What helped me come to terms with that was thinking about subagents, which are entirely about a Claude model setting up a prompt for another Claude model.
  
  Thariq: Workflows are actually a really good example of this, because it's Claude not just prompting a single subagent, but prompting the orchestration of many subagents, and each one of them gets a very detailed prompt. It's almost a level above just spawning a subagent. I've also been using it on my personal machine, giving it the Gemini API and saying: here, generate images. It's way less lazy than I am at prompting an image model. It's just Claude prompting Claude all the way down.
  
  Cat: I think Claude also wrote the prompt for the workflow tool.
  
  Simon: I've read that prompt — it's a good prompt. That's actually a frustration I have with Anthropic generally: you publish the prompts for Claude Chat, but you don't include the tool prompts and the Claude Code prompts. I still have to run a proxy to intercept them. I would love it if the Claude Code prompts were deliberately published — they're the documentation. They're how you know what the tool can do and how it works.
  
  Cat: I'll write down that feature request. I'll have Claude Tag do it.
  
  Interesting to note that OpenAI's prompting best practices for GPT-5.6 includes similar advice for their latest models:
  
  Favor leaner prompts
  
  Removing repeated instructions and examples and simplifying tool descriptions can improve task performance and token efficiency. In a sample of internal coding-agent eval runs, configurations with leaner system prompts improved evaluation scores by roughly 10–15% while reducing total tokens by 41–66% and cost by 33–67%.
  
  What's your bar for introducing a new tool?
  
  28:06
  
  Simon: Claude Code is basically a big bag of tools. What's your bar for introducing a new tool? How do you decide when it's worth doing that additional engineering at that level?
  
  Cat: Do you want to take it? You introduced one of the best tools we have.
  
  Thariq: My career peaked when I introduced the ask user question tool. It's really hard. Especially for some tools — ask user question is Claude's tool to ask you — so it's hard to eval, and sometimes it's more of a user preference thing. Back then we had fewer evals, so it was very dogfooding based — or "ant fooding," our ant version of that. But overall we've been trying to trend towards fewer tools. The last set of tools we introduced was the task tool, I think — and we try to give Claude more general versions to do things.
  
  What's the latest evolution of your file editing tool?
  
  29:03
  
  I have a long-running fascination with file editing tools - they were the subject of the old Aider code editing leaderboard, and I've watched with interest as they've evolved in different coding agents from search-and-replace based to line-number-based to more complicated patterns.
  
  The Claude API docs describe a text editing tool that's recommended for building against the API, but Claude Code seems to use slightly different approaches here.
  
  Simon: One of the most interesting tools is the file editing tool — you can have file editing as a tool, or you can tell it to use sed and grep and do things that way. What's the latest evolution of your file editing tool?
  
  Thariq: We still have one, but for example we removed our grep and other search tools — glob tools — in favor of native bash. Like I said in my talk earlier, the models are kind of more of a biology than a physics, and tool design especially is quite hard. I'm not sure if Cat disagrees and thinks there's a science to the eval of it, but I think tool design is more of an art, maybe — or a biology.
  
  Cat: I largely agree, but in general as we introduce more tools, we try to keep the cardinality pretty low and make sure that every tool we add has a distinct function from every other tool, so that Claude can very easily distinguish when to call each. For file edit, the reason we have it is actually because we can render it. We show people when Claude makes a file change, and there's this nice dedicated UI that says: do you approve this edit to this file? The reason we had a dedicated file edit tool was so that we could deterministically know that Claude was making a file change, so we could show people this nice UI. A lot of new users onboarding still really like this experience, so we've kept it around. But for a lot of us who are on auto mode right now — hopefully you're not on YOLO mode — I don't think it actually matters, and we could probably just remove file edit and be totally fine.
  
  What's the advice within Anthropic for safely running Claude Code?
  
  30:58
  
  It's the prompt injection question! Who better than Anthropic employees to explain how Anthropic sees the risk of prompt injection attacks causing their Claude Code instances to run amok?
  
  It turns out they really trust their auto mode - and see that as the feature that enabled Claude Tag.
  
  Simon: Let's talk about safety and security. I am deeply aware of the risks of prompt injection, and there are so many bad things that can happen if somebody else tells my Claude Code what to do. I still mostly run Claude Code in YOLO mode and feel incredibly guilty about it. What's the advice within Anthropic for safely running Claude Code?
  
  Cat: Why not auto mode?
  
  Simon: I am starting to use auto mode, but I don't understand it enough to get how safe it is. As of maybe three weeks ago, I'm defaulting to auto mode.
  
  Cat: Broadly within Anthropic, almost every single person uses auto mode. It is the best way to do long-running work in Claude Code while being safe. We've done extensive bashing. We have thousands of evals. We've commissioned many red teamers to create adversarial environments in order to trick Claude Code into doing bad actions, and we've mitigated every single issue that they found. We're going to publish some evals in the coming weeks, but we've pretty much mitigated every attack.
  
  Simon: That is a big claim.
  
  Cat: We'll share the evals for it so folks can assess, but we've been extremely diligent about identifying all the ways in which Claude might mess up and then updating auto mode to counter it. It doesn't catch 100% of things — that would be way too strong a claim. But for the main categories of risks that we're concerned about, like prompt injection and data exfiltration, the risks are far lower than the average human reviewer.
  
  I am very much looking forward to learning more about their evals and approach to verifying auto mode.
  
  Thariq: A little on how auto mode works — it's useful to build this mental model. Whenever Claude is doing a turn, or a bash call, there's a Sonnet classifier that is judging the tool call and also the context of the conversation — your instruction. There are some things around permissions that are dependent on your request: you don't want to give git push permissions all the time, but if you say "push this to GitHub," you want it to do it — and if you say "don't push," you want it to deny it. Auto mode will do that. That particular thing happens to me a lot, where Claude tried to do something because it's very helpful and proactive, and auto mode saw "don't do this" and surfaced it. So it's good at the dynamic permissions that you yourself give inside the prompt, which I think is really important. It also works well with our sandboxing infrastructure, because sandboxing is one of those things where there are so many different edge cases that it's hard for us to deterministically follow them. We have a sandbox, and when something needs to escape the sandbox — like a network request — auto mode can look at that request and ask: does this make sense? — and allow it.
  
  Simon: I hadn't realized auto mode is interacting with the networking sandbox as well.
  
  Cat: It interacts with any permission prompt the user would otherwise see.
  
  Simon: How old is auto mode? As a feature I had access to, it's only a couple of months old, right?
  
  (It was first made available to the public on March 24th.)
  
  Cat: We've been using it within Anthropic since January, so we've been hardening it for quite a while. Anthropic is extremely focused on safety and security, and we've been working broadly across our alignment and safeguards teams to enable the rollout internally, build out these evals, and make auto mode even more robust before sharing it with the world.
  
  Thariq: This is also the reason Claude Tag is so good — Claude Tag uses auto mode. I've heard a lot of build-versus-buy questions about a Slackbot, and I'm like: please, you probably shouldn't build your own AI Slackbot. There are so many attack vectors. You have a feedback channel that users can post feedback into, and now your bot is reading it. The work we've put in with auto mode — and we have a general Swiss cheese defense for security; we also RL against this stuff — I think this is really what makes Claude Tag work. It works seamlessly with your permissions, and you don't want to be prompt injected in your Slack.
  
  Are there more security things in the pipeline beyond auto mode?
  
  35:54
  
  Simon: Are there any more security things in the pipeline that go beyond auto mode?
  
  Thariq: I think we're very secure. With Claude Tag you can provision your own credentials for Claude, so it doesn't need to act on your behalf — you can have Claude as an identity, and that also makes it easier to audit and inspect what Claude is doing.
  
  Simon: Because Claude Tag is influenced by anyone who can talk to it — it's got a much wider pool of people telling it what to do.
  
  Thariq: That's right. And of course we have probes as well with Fable, which is a downstream effect of our safety and research work. I think this is the moment where you see Anthropic being an AI safety company really paying off: we really want Claude to be able to run in an aligned way over long periods of time, and auto mode has to be basically flawless for this to work — it's all downstream of our being an AI safety company.
  
  Cat: We also launched trusted devices for the remote control users out there who want to be safer. And for all of our remote environments, we support credential injection. If you want Claude Code to be able to access Datadog, but you don't want Claude Code itself to hold the Datadog credential, you can set up our identity and credential management system so that the Datadog credentials are only usable by the agent but not accessible by the agent — we insert them on the fly when the agent tries to make a Datadog request.
  
  I really like that credential injection pattern, where Claude Code can access an API via a proxy and that proxy both audits the request and injects the relevant API key - so Claude can access authenticated endpoints without having access to the API credentials itself.
  
  How has the past year and a half changed how you think about your own craft?
  
  37:53
  
  Thariq talked about a sense of grief brought on by Fable-class models in his keynote in the morning, and we dived further into that as part of our conversation. I've been calling this Deep Blue.
  
  Simon: Let's talk a little bit about the human element. A lot of people are feeling a sense of loss now that so much of what they considered to be their role in building software is being subsumed by the models. How do you think about that? How has the past year and a half changed the way you think about your own craft and the value that you add?
  
  Thariq: Cat and Boris are such good reminders that you have to be more ambitious. They're always like: we're growing so fast, we have to be on the edge, we have to do the best work we can. That's a constant reminder for me — any time I'm slow on something, I'm like, okay, can I do it faster? Can I be more ambitious here? And oftentimes the answer is Claude, because Claude is getting better as you go — the last time I tried this, it was with the previous model. On your point about loss: I think this is real. If you're only trying to do the same work you were doing before LLMs, and now it's a prompt, it is, I think, kind of a sad feeling. And the way you offset that is by being more ambitious. I think Jared is such a good example — he hand-wrote all of the Zig code in his Oakland apartment in about a year, barely left his house, and had so much fun doing that. Now I see him rewrite all of Bun into Rust and he's having so much fun doing that — it's so much more ambitious, and that's how he offsets it. Generally it's asking how do I do the bigger thing and do more — I think success is fun. It's changing your ambition.
  
  "The way you offset that is by being more ambitious" neatly captures where I've landed on this issue myself as well.
  
  Simon: And Cat, what does that look like from a product management perspective?
  
  Cat: I feel like the product role just changes every single month. All the PMs on our team are this mix of engineer, designer, PM — most of them actually used to be full-time engineers. For us it really means plugging in whenever there's any kind of gap. If we have an idea and we didn't inspire any engineer to go build it, then we should just build it, put it into a notebook, and inspire people to take it to production. If the designs look a little off, let's take a page that's similar, do a first-pass design, and tag in someone who's very detail-oriented to fill in the gaps. Or if we notice that our team and product adoption is bigger within the company, and more people need to know what's coming down the pipe for Claude Code, Claude Tag, and Cowork — let's automate figuring out our whole launch calendar, let's automate getting those status updates asynchronously so we're not bugging people, and make sure our updates in our internal announce channels are fully detailed and to the point. For us it's very much understanding what the gap is right now between a great idea and getting something to our customers, and how do we automate it as much as possible.
  
  This reflects something I've noticed: when you can produce code so much faster, time spent blocked awaiting a decision from someone else becomes a much more notable bottleneck. Engineers who can make product decisions can move a whole lot faster, and the cost of getting one of those decisions wrong is much less prohibitive.
  
  What's a moment when Claude has surprised you?
  
  41:50
  
  Simon: What's a moment when Claude has surprised you? When the model did something you didn't think it would be able to do?
  
  Thariq: I've posted a lot about Claude video editing, but most recently I gave a talk at the ACM Agentic conference, and I asked, "Hey guys, do you have the edited video? I'd love to post it and share it with my comms team." They said, "Oh, it's taking so long." So I asked for the raw files. They sent me the video of me talking on stage, the video of the deck, and the audio file, and said, "Good luck." I gave this to Claude, along with my HTML deck, and said, "Hey, can you just edit this together?" And what it does is honestly incredible — I'm ready to ship it. It transcribes the entire video. It notices that sometimes the video of my deck is a little weird — there's a popup of an auto-update in the middle — and it goes, "Oh, I probably shouldn't use the video of your deck. What I'm going to do is slice it up, figure out which slide you're on, and use the HTML source instead." So it displays the HTML source. Then it's got video of me, but I'm only taking up a small part of the stage, so it's cropping dynamically to where I am on the stage — and I'm pacing, so it's tracking me as I pace. And it's transcribing what I'm saying.
  
  Simon: This was Fable, right?
  
  Thariq: This was Fable, yeah. It was a good prompt, but it was a one-shot prompt. Then I asked it to add some interesting animations and graphics, and I was just blown away. It does ffmpeg, it does Remotion.
  
  Here's Thariq's video on how he used Fable to edit Fable's own launch video, and here's that launch video.
  
  What can't it do yet?
  
  43:36
  
  I'm embarrased to admit that I've been finding it quite hard to come up with tasks that frontier models like Fable 5 and GPT-5.6 are unable to accomplish.
  
  Cat still doesn't rate its UX design skills:
  
  Simon: What can't it do? What are the things where you're still disappointed — where you're waiting for Claude Fable 6 to figure it out for you?
  
  Cat: I want it to have better design and UX taste. It's now at the point where if I write out a prompt with a detailed spec of how I want a feature to behave, it will usually behave that way. But the paddings might be off, or the interface just isn't delightful yet. It leans on existing best practices for how apps are designed, but for frontier AI products, there are so many new interaction experiences that we have yet to design.
  
  Simon: There's an Opus aesthetic — you can look at something and go, "Yeah, that was designed by Opus." It'd be good if we could move beyond that.
  
  Cat: Yeah. I'm very excited for future models to hopefully be interaction design thought partners.
  
  Thariq: What can't it do? I would love to see it interact more with the real world. Can it solve science? Can it orchestrate the experiments? There's some amount of coding that goes into that, but there's also this other taste of the broader world that it needs.
  
  Which parts of Anthropic's culture should other companies steal?
  
  45:11
  
  I figured this would make a great closing question:
  
  Simon: Which parts of Anthropic's company culture do you think uniquely help Anthropic be productive with these tools, that other companies should steal? What are the cultural hacks people should be adopting from you?
  
  Cat: I'll share one for Claude Tag. Claude Tag works best when you have it in a public channel, and when most of your channels are public. Claude Tag is able to search across all public channels to get as much context as possible to give you the highest-accuracy answer — and it's only able to do this if it has access to everything.
  
  Thariq: I mentioned this in my keynote, but it's so important to me I want to re-emphasize it. The co-founders say we don't negotiate against ourselves, and I think this is really important. You can imagine trade-offs in your head and talk yourself out of doing something ambitious — or you can just try to do the ambitious thing. We're so often asking: what if we just did it? Is this a real trade-off or not? And if so, why — where's the proof that it's a real trade-off, and not just something that sounds reasonable? Make the trade-offs show themselves to you. Be as ambitious as you can.
  
  What's your favorite absurd thing you've built with Claude, just because you could?
  
  46:46
  
  I couldn't resist throwing in this one as well.
  
  Simon: What's one of your favorite absurd things that you've built with Claude, just because you could build it?
  
  Thariq: I'm working on a 2D Street Fighter fighting game with me as a character — and my friends as well. It uses Claude Code to prompt Gemini — and honestly the Seedance model is pretty good — to make video animations. It works great; it's so good at prompting, and it can verify the frames to check whether an animation was good.
  
  Simon: Is this Street Fighter 2-level 2D sprites you're generating?
  
  Thariq: Yeah, exactly — 2D sprites. The animation looks amazing. And it can also figure out hitboxes — it can be like, "Oh, your fist is here, I'll draw the JSON hitbox." It's incredible.
  
  Cat: Mine is much more simple. I'm a big rock climber and a lot of my friends climb, so we have this little app we built with Claude Code where we log all the projects we're working on. We also go outdoors together a lot, so we have Claude do all this research with workflows. Workflows is amazing — we brand it as a coding tool, but it's amazing for doing deep research for travel. I also plan our team offsites, and it's good at finding venues that can fit all of us. I use workflows to research all the climbing destinations we might want to go to, and what has direct flights from where all of us are located. It goes to Mountain Project and finds all the climbs at our grade level. It finds the Airbnb. And I don't like hiking, so I care a lot about it having a very short approach — very short walking distance from where the car parks to where the rock actually is — and it filters for this. With existing apps I have to manually click through Mountain Project, but with this I just put in all of our preferences and it's a custom app for us.
  
  Simon: So you're basically vibe coding Jira for mountain climbing.
  
  Cat: Exactly.
  
  Audience: Any plans for eval-building tools and agent observability?
  
  49:23
  
  We had a few minutes at the end for questions from the audience.
  
  Audience: Do you have any near-term plans to build more eval tools for us to build eval datasets, and more observability tools to monitor the performance of agents and workflows?
  
  Cat: We've considered building eval tools, but I think the limiting factor actually tends to be that it takes a long time for customers to build really high-quality evals. So I think the tooling is less of the constraint, and more the skill set of how you build a great eval. That's an area where we're excited to both invest internally and hopefully share some best practices externally.
  
  Audience: How is memory designed today — and would you move from files to a data store?
  
  50:08
  
  Audience (Sai): I'm interested in the memory and the multiplayer. How is memory being designed today? I assume it's around files. And second, have you thought about an orthogonal direction where you would actually need a data store for these memories, instead of files, to scale it better?
  
  Thariq: Right now for Claude Tag the memory is channel-specific. Every Claude in that channel has a shared memory, and the instances have a session — but the session can contribute back to main memory. We do a lot of memory research, and it can be kind of unintuitive what the right way to do memory is. We're always running memory experiments. How it works right now in Claude Tag is a markdown file per channel.
  
  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.
6. 🔗 r/reverseengineering Desktop+ Lockscreen Animated Wallpaper Fully RE of WallpaperExtensionKit.framework private apis (Still Buggy) rss
  
  submitted by /u/KepcukTheGreat
  [link] [comments]
7. 🔗 HexRaysSA/plugin-repository commits sync repo: -1 plugin, +2 releases, -2 releases, ~1 changed rss
```
sync repo: -1 plugin, +2 releases, -2 releases, ~1 changed

## New releases
- [llm-explainer](https://github.com/pgarba/ida-llm-explainer): 1.9.0, 1.8.0

## Changes
- [binexport](https://github.com/hexrays-plugin-contributions/binexport):
  - 12.0.0: archive contents changed, download URL changed

## Removed plugins
- aida
```
8. 🔗 pydantic/pydantic-ai-harness v0.8.0 (2026-07-20) release
  What's Changed
  - Add .macroscope/ignore.md to skip mechanical files in review by @strawgate in #387
  - Clarify CodeMode final-expression returns by @adtyavrdhn in #370
  - feat(step_persistence): rescue last provider-valid resume point on error by @dsfaccini in #384
  Full Changelog : v0.7.1...v0.8.0
9. 🔗 seanmonstar Micro: Accessors can reveal internal representation rss
  
  As a library maintainer, it’s common to receive requests from users to add a “simple accessor”. The data is right there. But that accessor can end up revealing internal representation details that you can no longer change.
  
  This is one reason why it could be a better practice to return an impl Iterator instead of &[T]. The latter freezes you in place to always storing the data in consecutive memory. (Such as String::as_bytes().)
  
  View types might help too, like Ref<'_>. Returning a reference requires the data already exist in that shape in self. You can’t change its shape in the accessor and return a reference to that.
10. 🔗 Julia Evans Some more things about Django I've been enjoying rss
  Hello! I'm on a funny journey right now where I'm trying to learn how to make websites in a sort of 2010 style, where I have an SQL database and render some HTML on the backend.
  
  It's kind of an interesting journey because it doesn't necessarily feel "easy" to me to make websites in this way: I never learned how to do it in the 2000s or 2010s, and there's a lot I need to learn.
  
  So here are some Django features that make building this kind of site feel more achievable than when I was trying and failing to use Go's standard library or Flask. And I'll talk about a couple of issues with Django I've run into.
  
  why learn to make websites like it's 2010?
  
  Previously the toolkit I felt confident with for making websites was:
  - static site generators (like for this blog)
  - static sites that do some fun stuff with Javascript (like this sql playground)
  - simple Vue.js single page apps with either a Lambda as a backend or a Go backend (like mess with dns)
  I really liked this frontend-heavy approach for these super simple applications but when I started thinking about making something with a lot of different pages (instead of literally just one page), I didn't feel so excited about the options I saw that involved a lot of frontend code. So I figured I'd try the backend.
  
  Writing a backend-focused site that uses as little JS as possible feels the same to me in a way as writing a single-page JS website that does as little on the backend as possible, even though they might seem like opposites. In both cases I'm just trying to keep as much of the logic as possible in one place.
  
  Now for some thoughts about Django!
  
  I'm enjoying query builders
  
  I learned that I can define a "query set" class in Django with a bunch of methods with different WHERE statements I might want to use while constructing a query:
  
  Here's how I use it in my view code once I've defined what all the methods mean:
```
Events.objects.approved()
  .for_tab(tab)
  .with_festivals(tab_params.festival_slugs)
  .is_free(tab_params.free)
  .is_outdoors(tab_params.outdoors)
```
  and here's how I define the methods:
```
class EventQuerySet(SearchableQuerySetMixin, models.QuerySet):
    def approved(self):
        return self.filter(approved_at__isnull=False)

    def future(self):
        today = timezone.localdate()
        return self.filter(end__gt=self._midnight(today))

    def with_tags(self, tags):
        if tags:
            return self.filter(tags__name__in=tags).distinct()
        return self
```
  The syntax for defining the filters isn't my favourite, but I spend most of my time just using the methods, and it feels super readable and nice to use, and it makes me want to look into other query builder libraries in the future. In the past I thought "I know SQL, who needs a query builder?", but this kind of structure does make it really nice to read.
  
  I found an example of someone who wrote their own small query builder in Python that I want to read later to think about whether I would enjoy using a more minimal version of this.
  
  the template filters are awesome
  
  There are a bunch of little quality of life filters available in Django templates that are super useful for generating HTML. The ones I've used so far are:
  - translating plain text URLs into links, or line breaks into <br> ({{ event.description|urlize|linebreaksbr }})
  - formatting dates ({{ row.date|date:"M j" }})
  - json_script, which takes a Python dictionary and automatically converts it to JSON and inserts it into the HTML as a <script> tag in a safe way
  These are all small things individually but I feel like it makes a big difference somehow to just have them available.
  
  querystring is cool
  
  I think my favourite template filter is querystring: in this site sometimes we use filters like ?date=2026-06-01 to decide what's displayed. querystring that will make a link to the same query string with one change, like this to link to the previous date:
```
<a href="{% querystring date=nav.prev_date%}">
```
  Or to remove the outdoors parameter:
```
<a href="{% querystring outdoors=None %}">
```
  automatic database migrations are still great
  
  I still really love Django's automatic database system. It's amazing to be able to just edit a model to add a new field or whatever, and then Django automatically generates the migration.
  
  So far we have done 19 database migrations and I think there will probably be more! It makes a huge difference for me to be able to just easily change the database as my understanding of the problem changes.
  
  I do not want to organize my code with inheritance
  
  Django's documentation sometimes offers the option of using class-based views and inheritance to organize the code in your views. For example I have four views that share a lot of code, and I could use inheritance to manage that by defining some kind of parent class and then having my other views inherit from it.
  
  I tried it out and I did not enjoy the experience of using inheritance to share code between views. I switched to using functions instead, sort of how this post advocates, and that was a lot more straightforward. I've never had a good experience using inheritance in Python and I don't think I'll try to use it again.
  
  But I don't mind using inheritance to use the interfaces Django itself provides: for example if I want to define a query set I need to write something like class EventQuerySet(SearchableQuerySetMixin, models.QuerySet). I don't think too hard about it and it seems to work.
  
  (as a meta comment: I've been working on talking about my programming opinions by just saying "THING does not feel good to me, I prefer OTHER THING instead". That post I linked to says that function-based views are the "right way". I'm not very invested in whether it's "right", but it's validating to know that other people feel similarly to me about inheritance)
  
  I don't know how to think about Django performance
  
  At some point the LLM scrapers discovered our site, and started sending us maybe 10 requests per second. I blocked them which is working for now, but it made me think about what the site's capacity is. I'm used to writing Go backends where the performance situation is pretty straightforward (usually everything is just fast enough), and a Django site is very different.
  
  Some light load testing (with (ab -n 1000 -c 1) shows that right now we can serve about 2-3 requests per second (on a ~$10/month VM).
  
  It's tempting for me to go down a rabbit hole where I do a bunch of profiling to figure out what's slow and try to make it faster (there's py- spy for that, and py-spy is great and super easy to use, and profiling is fun!) But I really don't understand what I should expect in terms of performance from a Django site and how I should be thinking about at a higher level.
  
  Some things I haven't figured out yet:
  - If I have a site that's going to be getting occasional bursts of traffic, do I want to be able to scale up?
  - Do I want to design the site so that more things can be cached? (and do I really have to? caches are so annoying to get right!)
  - The django performance docs say that Jinja is faster for templating, do I want to think about switching templating systems?
  - Those docs also say "{% block %} is faster than using {% include %}", I wonder if it's a big difference and if so why
  template caching might be important
  
  I think one thing I'm learning about Django is that because it's a Framework (tm), it's easy to accidentally misconfigure it. For example, when I was thinking about why my site was slow just now, I read the django performance docs and I noticed a comment saying:
  
  Enabling the cached template loader often improves performance drastically, as it avoids compiling each template every time it needs to be rendered.
  
  When I'd done CPU profiling I'd noticed that it was spending a lot of time rendering templates! Maybe this could help me!
  
  Clicking through the link, I saw that the cached template loader was supposed to be on by default, but I'd turned it off by accident while trying to do something else. I think this "I turned off the cached template loader by default" things is an example of how I still find the django settings file to be pretty confusing and difficult. I guess I should just be careful when I go in there.
  
  After turning on template caching, it seems like the site can now pretty easily handle 12 requests per second or so without using all of the CPU. I have not carefully benchmarked the before and after but it seems like it's made a pretty big difference.
  
  One thing that's been surprising to me about Django performance is that I've always heard the advice "if you have a performance problem, check your database queries! Maybe add an index!". But I've been running into a variety of performance issues (like this template caching thing) that are not because of slow queries, so instead it's been more useful for me so far to start by running a CPU profile. And since I'm using SQLite, any slow database query problem will show up on the CPU profile anyway.
  
  Anyway I don't want to get too far into site performance. Like I said it's easy for me to get interested in profiling, but actually I know a lot about profiling and it's not the most important thing for me to learn about.
  
  that's all for now!
  
  I might say more about what I'm enjoying (or having a hard time with!) about Django later. Trying to write some shorter blog posts recently.
11. 🔗 exe.dev Customizing Shelley, Customizing Software rss
  
  Asking Shelley to make itself pink.
  
  Sure is pink.
  
  Pink upgrade screen automates rebase.
  
  ‹
  
  ›
  
  If you want to customize Shelley, open up a conversation, and ask the agent to change itself. It will do so. When a new version of Shelley ships, it rebases your customizations onto the latest version, so your changes always carry forward.
  
  The traditional approach to software customization has been configuration and plug-in architectures. With the advent of coding agents, a third way is viable: edit the code. The tool exists to serve you, so treat it like a wiki, slap an "Edit With Shelley" ribbon on it, and go to town.
  
  Give customizing Shelley a shot! When you've got features that can stand the test of time, pop into our Discord, and let us know.
12. 🔗 exe.dev How Antithesis Turned exe into a Sandbox for Agentic Software Tests rss
  
  Carl Sverre spends a lot of time thinking about how to give AI agents the right amount of power. Give them too little, and they can’t do real work. Give them too much, and they might blow up your tech stack. As a software engineer at Antithesis, an autonomous software testing platform, that question is core to how Sverre thinks about designing tools in the era of advanced AI.
  
  The solution he found began with figuring out the ideal place for agents to work. At the start of this exploration, he tried out the obvious options but found himself frustrated by their restrictions. Local sandboxes in particular were too limiting. "As soon as the AI wants to do something out of that boundary, it gets blocked," Sverre explains. The bigger platforms, in contrast, were designed for shipping AI products. What he actually wanted was something simpler: "I just realized what I wanted was, like, a computer," he says.
  
  That’s when Sverre remembered exe. “I was like, ‘oh, yeah, like, David is doing this weird little AI project,’” he says. He signed up and launched his first VM. “I was just so impressed by the UX,” he says. “It was so easy. And then the pricing model was perfect. It solves, in my opinion, the most critical issue with sandboxes.”
  
  That issue, in a nutshell, is that many sandbox providers charge per VM. Spin up ten sandboxes, and you pay for all ten, whether or not you’re using them simultaneously.
  
  Exe works differently. A team account, which costs $25 per user per month, gives each person access to up to 50 VMs that draw from their own pool of resources. Nobody has to track how many they’re running or whether they’ve remembered to shut them down. "I don't want to ever have to feel like I'm spending money when I create a sandbox," Sverre says. "I shouldn't have to worry about my finance team asking me why I spent another two dollars."
  
  Sverre quickly incorporated exe into his workflow. As a bug catcher, a lot of his work revolves around testing open source projects. "I basically just changed my workflow to be like, spin up an exe machine, check out the project, open up Claude, ask a bunch of questions, and then throw away the VM," he says.
  
  Some projects, however, need more than a one-off VM. Sverre does much of the development for Snouty, Antithesis’ command line tool, inside a persistent machine. "I have Claude running there and I drive that VM through Claude remote control," he says. "I basically just have access to a persistent Claude session on my phone and on the web browser."
  
  In exe’s early days, Sverre noticed that any user could click a button and share their VM with the public. “I immediately was like, that's just not a thing we can have," he says. Luckily, with a small startup, that was an easy fix.
  
  Sverre filed a feature request with exe engineer Philip Zeyliger. "Two or three days later, it showed up in the product," Sverre says. The solution—restricting who can make a VM public—allowed him to roll exe out more broadly. "I don't have to worry as much," he says.
  
  Sverre keeps coming back to two core differentiators. First, root access: "We love the fact that you have root on the VM. So the AI can do basically whatever it needs to do to accomplish some task, which is really nice,” he says.
  
  Second, how exe handles idle VMs. "Every other VM platform on the planet hibernates your VMs," he says. "Exe is the only one that doesn't do that." In practice, it works out the same—an idle VM's resources get used by other VMs instead—but there’s no delay when an idle VM boots back up. "You never have to think about, is it running, is it not running.”
  
  Sverre is now thinking about what an expanded version of this workflow could look like—VMs that spin up other VMs and divide up work automatically. "I'm right on the edge of building more of an automated software factory where I want to have VMs be created by other VMs," he says. It's still early days, but the underlying question hasn't changed: how much power do you give an agent to work—and how do you make sure it’s totally safe?
  
  "There's this tension between giving them enough power and then also not letting them destroy the world," Sverre says. "exe is that solution for us."
13. 🔗 Ampcode News Right on Schedule rss
  Agents in Amp can now set their own schedules and wake themselves up. When a schedule fires, the agent wakes up with its saved prompt and continues right where it left off, with all of its context and history. Works great with Slack, Puck, and spawning other agents, too.
  
  You can now say things like:
  - "Every morning, dig up the five slowest database queries of the past 24 hours, investigate with an orb in ultra mode, and DM me the list on Slack."
  - "Merge this, and remind me on Slack in two days to clean up the feature flag and roll it out to everyone."
  - "My recent backfill job thread, check on it every ten minutes and ping me if it stalls or starts outputting errors. Let me know when it's done."
  - "Every hour, use the inference-error-triage skill to inspect errors from the last hour and group related ones. For each newly discovered group, spin up a new thread to fix the errors and report back in the #bugs Slack channel."
  Here's a real schedule at work: a thread watching a long-running job until it's done.