iiinova — where your digital self keeps evolving

Connor Shea @connorshea.bsky.social · 28/09/2026

I wonder how much energy we could save if we banned hotels from leaving TVs on in rooms

010 0

Connor Shea @connorshea.bsky.social · 18/09/2026

My conclusion here is that we need to rewrite every image codec in Rust. www.hacktron.ai/blog/hacking...

hacktron.ai

Hacking OpenAI

A heap overflow and SSO misconfiguration to compromise OpenAI internal repositories

000 0

Connor Shea @connorshea.bsky.social · 15/09/2026

I think this is fixed by oxlint 1.81.0 and above, please tell me if you still see the problem after updating, and apologies for the trouble! (I think this is the same issue as github.com/oxc-project/... but for Zed instead of VS Code)

000 0

Connor Shea @connorshea.bsky.social · 10/09/2026

It's insane how much more transparent and detailed the Anthropic blog post is compared to the OpenAI one, despite the Anthropic incidents being considerably less concerning. www.anthropic.com/research/ali... vs openai.com/index/huggin... They're also giving METR far more access, it sounds like.

anthropic.com

An alignment assessment of recent cybersecurity incidents

We present an alignment assessment of four incidents in which Claude models gained unauthorized access to real third-party systems.

000 0

Connor Shea @connorshea.bsky.social · 05/09/2026

The only reason I bring this up is because most of the gems in the spam attack were benign and very weird, usually linking to/repackaging data from local UK government sites.

110 0

Connor Shea @connorshea.bsky.social · 05/09/2026

collusion.wiki/index.html This has also been linked to gems on RubyGems which dumped data to share with other agents. I wonder if this is potentially related to the attack in May? The second screenshot is mine, that I took on May 11 (12th in UTC) when I noticed spam on RubyGems.org.

100 0

Connor Shea @connorshea.bsky.social · 29/08/2026

Pseudo-type-aware? Oxlint fully supports type-aware lint rules with tsgolint. We ported all but two of the type-aware rules, unless you mean custom type-aware rules? oxc.rs/docs/guide/u...

oxc.rs

Type-Aware Linting | Oxlint

Linting with type information.

110 0

Connor Shea @connorshea.bsky.social · 28/08/2026

This absolute piece of shit president...

000 0

Connor Shea @connorshea.bsky.social · 10/08/2026

Awesome to see Sentry potentially migrate the monorepo! I've been using it for benchmarking on some rules. What does the `--debug=timings` table look like for Sentry on Oxlint 👀 I assume most of the time is in JS Plugins though, which we don't report detailed timings for yet IIRC

210 0

Connor Shea @connorshea.bsky.social · 03/08/2026

We've already scraped away most of the optimization opportunities available over the last few months, though some definitely still exist.

110 0

Connor Shea @connorshea.bsky.social · 03/08/2026

I don't think I have any specific tips beyond just making sure you always do as much verification as possible of a perf change, especially one that has significant impact. You're free to look around the ruleset for optimization opportunities, I don't have any specific rules unfortunately.

110 0

Connor Shea @connorshea.bsky.social · 03/08/2026

I'm also hugely appreciative to the main Oxlint maintainer Cam, for all the reviews he's done on my PRs and pushback when the changes are too complex or don't look quite right :) Having other devs who are very experienced and knowledgeable in Rust and perf work has definitely helped me improve.

110 0

Connor Shea @connorshea.bsky.social · 03/08/2026

Oxlint is also just a pretty good project for this kind of thing because there are nearly 850 rules and so there'll always be simple optimizations scoped to single files that can be found. Other projects it may not work as well. Though I've also found it pretty good for DB query optimization at work

120 0

Connor Shea @connorshea.bsky.social · 03/08/2026

It will gladly give me slop which only saves very slightly more time for an exponential increase in the diff size/code complexity. So you have to guide it properly or have it really prove out its changes. If something looks too good to be true, it's probably Claude being goofy or mistaken.

230 0

Connor Shea @connorshea.bsky.social · 03/08/2026

But you have to be wary of it doing stupid crap that barely gets any performance improvement. e.g. see the final diff I submitted (github.com/oxc-project/...) vs. the original that Claude gave me (github.com/connorshea/oxc/commit/25d1f95f9e5a3302e73428620c379a648174027d)

120 0

Connor Shea @connorshea.bsky.social · 03/08/2026

With sufficient guidance and a good setup for benching it definitely can be very good for it, but it depends on the project. I think, same as doing it manually, you'll always try things and some % won't work out. I throw out a solid chunk of perf changes Claude tries or suggests to me.

120 0

Connor Shea @connorshea.bsky.social · 03/08/2026

Usually hyperfine or Claude-written Python scripts to interleave the runs. The `--debug=timings` flag for oxlint reports the timings on each rule, so you can get pretty good data on the runtime of a specific rule by running it interleaved and then pulling the rule's timings each run.

110 0

Connor Shea @connorshea.bsky.social · 03/08/2026

In today's Oxlint 1.77.0 release, import/no-cycle (our slowest Rust rule) gets more than 3x as fast!

Benchmark table: import/no-cycle on the vscode corpus drops from 3520.0 ms (1.76.0) to 1143.9 ms (1.77.0), a 3.08× wall-clock speedup, faster in all 15 paired rounds.

2402 0

Connor Shea @connorshea.bsky.social · 01/08/2026

What does the monorepo structure look like? I've had somewhat similar problems with my work codebase, but thankfully was able to resolve them since we only have one main tsconfig. Unfortunately supporting nested configs *and* multi-root workspaces is a bit messy

100 0

Connor Shea @connorshea.bsky.social · 01/08/2026

FWIW, you can use a lot of ESLint plugins with Oxlint (there are some holes in compatibility, though). oxc.rs/docs/guide/u...

oxc.rs

JS Plugins | Oxlint

A collection of high-performance JavaScript tools written in Rust

010 0

Connor Shea @connorshea.bsky.social · 30/07/2026

I haven't opened an IDE since college (VS Code doesn't count)

000 0

Connor Shea @connorshea.bsky.social · 28/07/2026

In next week's release of Oxlint, import/no-cycle gets a lot faster :) This is a benchmark of the wall clock time, memory allocations, etc. of running the rule on the vscode codebase.

Benchmark table of three builds: main (3341.9 ms, 330.98 M allocations, 1360.8 MB peak RSS) through the drop-two-Vecs-per-edge commit (1082.0 ms, 38.61 M, 1063.9 MB) — cumulatively 3.1× faster, 8.6× fewer allocations, 21.8% lower peak RSS.

070 0

Connor Shea @connorshea.bsky.social · 27/07/2026

oh also I didn't enable type-aware rules for this, that's also important to note.

000 0

Connor Shea @connorshea.bsky.social · 27/07/2026

also worth noting that some rules (like vue rules) don't do anything in the vscode codebase and so are basically non-factors here, so saying it's 784 rules is a bit more than are really running.

120 0

Connor Shea @connorshea.bsky.social · 27/07/2026

Oxlint 1.75.0 (released Tuesday) vs Oxlint main, with 784 rules enabled (disabled no-cycle because it's extremely slow, plus 3 new rules that aren't available on 1.75.0). No notable runtime improvement since it's parallelized across many threads, but still nice.

Benchmark table comparing allocation counts for corpus ~/code/vscode/src (7,368 files), counting global allocator, 2 reps each, run-to-run spread under 400 allocations (~0.0007%). Columns: metric, v1.75.0, main, delta, delta percent. Whole-process allocations 57,248,774 → 52,996,284 (−4,252,490, −7.43%). Allocations minus parse-only baseline 55,589,803 → 51,337,178 (−4,252,626, −7.65%). Bytes requested 7.77 GB → 7.44 GB (−328.3 MB, −4.23%). Allocations per file 7,770 → 7,193 (−577).

170 0

Connor Shea @connorshea.bsky.social · 26/07/2026

The auto mode classifier does block a decent % of problems, but it does not block all of them and a persistent Claude trying to do something stupid can still do damage. Plus a bug in auto mode's classifier would leave you basically defenseless if you don't have the sandbox enabled on top of it.

110 0

Connor Shea @connorshea.bsky.social · 26/07/2026

The main concerns are prompt injection resulting in Claude making requests to malicious endpoints, and Claude reading/writing files outside the repository/directory you're working on. If you sandbox it, the damage it can do - either due to its own goofy decisions or due to an attack - is limited.

220 0

Connor Shea @connorshea.bsky.social · 26/07/2026

we will make oxlint slower to fix this

020 0

Connor Shea @connorshea.bsky.social · 24/07/2026

Making some oxlint rules allocate less memory #rust

Table comparing allocation counts and memory usage before and after an optimization, across two corpora. For n8n TS: allocations dropped from 1,949,840 to 14,252 (-99.3%), and bytes from 110.4 MB to 4.1 MB (-96.3%). For vscode src/: allocations dropped from 2,310,741 to 6,524 (-99.7%), and bytes from 129.9 MB to 1.9 MB (-98.6%).

Table comparing allocation counts and memory usage before and after an optimization, across two corpora. For n8n TS: allocations dropped from 345,236 to 38,153 (-88.9%), and bytes from 49.4 MB to 8.8 MB (-82.2%). For vscode src/: allocations dropped from 398,191 to 57,689 (-85.5%), and bytes from 50.4 MB to 12.2 MB (-75.8%).

2190 0

Reposted by Connor Shea

VoidZero @voidzero.dev · 22/07/2026

Type-aware Linting via Oxlint is now stable 🎉 oxc.rs/blog/2026-07...

oxc.rs

Type-Aware Linting Stable

A collection of high-performance JavaScript tools written in Rust

220728 0

Connor Shea @connorshea.bsky.social · 21/07/2026

That most people use Claude Code in auto mode without sandboxing is insane to me

130 0

Connor Shea @connorshea.bsky.social · 19/07/2026

In my experience this kind of thing has mostly been fixed by making smaller changesets and a crapload of automated tests. If it's JavaScript (or another loosely-typed language like Python), TypeScript or equivalents can also help a lot as a safeguard in my experience. Linters also help a lot.

030 0

Connor Shea @connorshea.bsky.social · 19/07/2026

This has been merged and updated in Oxlint, so it'll go out with tomorrow's release! @boshen.github.io has also added benchmarking to oxc-miette and made further optimizations to the library, so diagnostic rendering should be quite fast going forward :D

010 0

Connor Shea @connorshea.bsky.social · 18/07/2026

It should also make things faster when you are configuring oxlint for the first time on a large codebase and end up with a lot of violations. And it won't matter for non-default output modes (the json output mode may also benefit a little bit). PR here github.com/oxc-project/...

github.com

perf: speed up read_span with bulk memchr line scanning by connorshea · Pull Request #211 · oxc-project/oxc-miette

TL;DR miette was going one-byte-at-a-time through the file from its start to where the diagnostic was in order to grab the code to render. With this PR, we just go to each line ending in the file a...

100 0

Connor Shea @connorshea.bsky.social · 18/07/2026

To be clear: In most cases this ultimately should not matter because your codebase would have 0 (or near 0) diagnostics on a lint run, BUT if you use warning-level for rules that you haven't fully fixed yet, this will make a difference when you have hundreds or thousands of those violations!

100 0

Connor Shea @connorshea.bsky.social · 18/07/2026

We'll see if it gets merged, but I have a potential optimization for the diagnostics printing in default mode for oxlint :) See caveats below, but if you have many lint violations in your project, this will have an actual impact on how quickly an oxlint run finishes and returns your results.

Built oxlint (release) against main of oxc-miette vs. this branch of oxc-miette — identical except for the version of the miette dependency — and measured full-directory lint runs with hyperfine (default rules, output to /dev/null). Since parse + analysis is byte-identical between the two binaries, the entire delta is read_span:

Then a table with the benchmarking results, with the following contents:

On canvas-lms we lint ~10k files, get 3,149 diagnostics, and on main that runs in 370 ms, and on this PR it runs in 224 ms. So a 1.65x speedup.

On the gitlab codebase we lint ~10.7k files, get 1824 diagnostics, and on main that runs in 579ms vs 438ms in this PR, so a 1.32x speedup.

On a synthetic stress test file (2MB file w/ 4k diagnostics), we have 1 file, 4000 diagnostics, and on main it runs in 5.53s vs 1.01s on this PR, 5.47x speedup.

120 0

Connor Shea @connorshea.bsky.social · 18/07/2026

Which part is slow for you? Specific rules or?

000 0

Connor Shea @connorshea.bsky.social · 10/07/2026

So is Anthropic ever going to update this dashboard, or? red.anthropic.com/2026/cvd/

red.anthropic.com

Anthropic's coordinated vulnerability disclosure dashboard

010 0

Connor Shea @connorshea.bsky.social · 09/07/2026

One of the companies porting everything to rust should definitely fund the Clippy team, it's one of the best parts of Rust and needs love :) blog.rust-lang.org/inside-rust/...

blog.rust-lang.org

Together for a healthier Clippy | Inside Rust Blog

Want to follow along with Rust development? Curious how you might get involved? Take a look!

041 0

Connor Shea @connorshea.bsky.social · 05/07/2026

Good news: I got CI on my project to finish in 1m23s, down from 2m45s Bad news: It fails now

040 0