DEV Community: Leo

Terraform 1.16 adds destroy-time Actions and lets child modules own their imports

Leo — Tue, 06 Oct 2026 10:24:10 +0000

I once kept a shell script called pre-destroy.sh in a repo for far longer than I'd like to admit. It took a final backup, poked an external inventory system, and only then let the pipeline run terraform destroy. Everyone on the team was a little scared of it, and nobody ever fully trusted it. Terraform 1.16 lets a lot of that logic move into the configuration, where the plan can see it.

HashiCorp's release post covers two headline changes. Actions can now fire on before_destroy and after_destroy events. Import blocks can also live inside child modules, so the root module no longer has to own every import.

Destroy gets its own hooks

The release post opens with the cases you'd expect: taking a final backup, deregistering an asset, or cleaning up an external system before the infrastructure goes away. You attach an Action to a resource through action_trigger in its lifecycle block and list the destroy event in events. The shape from HashiCorp's example looks like this:

action "example_cleanup" "archive" {
  config {
    resource_id = caller.id
  }
}

resource "example_service" "payments" {
  name = "payments"

  lifecycle {
    action_trigger {
      events  = [before_destroy]
      actions = [action.example_cleanup.archive]
    }
  }
}

For anyone who has wired up cleanup steps in a pipeline, this is the nice part. The cleanup step sits next to the resource it belongs to, it shows up at plan time, and you stop relying on whoever runs the destroy job to remember the wrapper script.

Imports that travel with the module

The second change is quieter, and I think more people will feel it day to day. Until now, an import block could target a resource inside a child module, but the block itself had to sit in the root module. HashiCorp calls that "an awkward exception" for modules that are supposed to hide their implementation details.

In 1.16 the module can carry its own import:

variable "existing_bucket_name" {
  type = string
}

resource "aws_s3_bucket" "this" {
  bucket = var.existing_bucket_name
}

import {
  to = aws_s3_bucket.this
  id = var.existing_bucket_name
}

The consumer passes a name and doesn't need to know any resource addresses:

module "logs" {
  source               = "./modules/log-bucket"
  existing_bucket_name = "<existing-bucket-name>"
}

Terraform evaluates the import in the context of each module instance, and per the post that includes nested modules and module calls that use count or for_each. If you maintain a shared module catalogue, adoption of existing infrastructure becomes something the module author designs once instead of every consumer working it out alone.

The rough edges you'll hit first

Three things stood out to me as the ones that will trip up a pipeline.

The configuration and trigger condition of a destroy Action must be fully known at plan time. If your cleanup inputs only resolve during apply, you'll need to restructure before this works for you.

You can't just delete the resource block. Removing the block also removes its action_trigger, so Terraform has nothing to invoke when it plans the destroy. HashiCorp's guidance is to set count = 0 on the resource and its trigger configuration first, then remove the block in a later change. That turns one pull request into two, so tell your reviewers why.

Failure behaviour needs an explicit decision. The modes are halt (the default, which stops dependent processing after an Action error), continue (errors become warnings) and taint. The post is careful to note that taint marks a newly created resource for replacement and does not make a failed destroy Action retriable. If your backup step fails during a teardown, continue lets the destroy go ahead anyway. Choose that one on purpose.

Smaller things in the same release

terraform state show -json and terraform workspace list -json give scripts machine-readable output.
terraform graph -format=mermaid produces a diagram you can drop into a pull request description.
The CLI output includes an HCP Terraform policy evaluation summary.
Linux s390x binaries are now available.

How this compares with other tools

Teardown hooks are an old idea. Terraform itself has long had destroy-time provisioners (when = destroy), which run shell commands as a side effect of the destroy. They work, but a provisioner is an escape hatch and reviewers tend to treat it as one. AWS CloudFormation handles the backup case declaratively with DeletionPolicy: Snapshot on supported resources, and uses custom resources for arbitrary cleanup on delete. Kubernetes uses finalizers, which block deletion of an object until a controller has done its cleanup. Terraform's version stands out to me for where it puts the decision: the cleanup appears in the plan and has a documented failure mode, so a reviewer can see it before anything is destroyed.

The plan-time constraint and the two-step removal mean my old pre-destroy.sh won't disappear overnight. Still, I'd move the backup step into an Action on the next module I touch. Next I'll be watching how teams handle continue in production teardowns, because that's where a well-meant shortcut will turn into a missing backup. If you've already put destroy Actions in a pipeline, I'd like to hear how you handled the failure mode choice.

A semicolon in a Codex branch name leaked its GitHub token. Scope decided the damage

Leo — Sat, 03 Oct 2026 10:24:21 +0000

A branch name with a semicolon in it was enough to pull a GitHub OAuth token out of OpenAI's Codex, according to a DevOps.com write-up of a critical flaw that BeyondTrust's Phantom Labs disclosed in March. OpenAI has fixed it. For teams wiring agents into their delivery pipelines, the bug matters less than the token. Its scope decided how far a single injected command could reach.

The mechanism

When Codex created a task container, it passed the target branch name into a shell command without sanitizing it first. Bash interpreted characters such as ;, &&, |, $() and backticks as shell syntax rather than as part of a name.

The proof of concept was short. Set the branch to main, add a semicolon to end the intended git command, then append a second command that writes the output of git remote get-url origin to a file. That remote URL held the GitHub OAuth token in cleartext. The researchers then asked the agent, in the prompt, to read the file back. Codex read it, and the token came back in the agent's own task output.

The write-up says the flaw reached every Codex surface: the ChatGPT web interface, the CLI, the SDK and the IDE extension. Researchers confirmed it could be automated to compromise multiple users sharing a repository. OpenAI spent roughly six weeks on iterative hardening before the issue was classified Critical and cleared for public disclosure.

Blast radius is a provisioning choice

The DevOps.com piece describes each wired-up agent as a new privileged identity. The agent clones a real repository and authenticates with a real GitHub credential, but it gets less scrutiny than a human with the same access would. A token limited to one branch of one repo turns this injection into an inconvenience. A token with broad organizational access turns it into an org-wide GitHub compromise that started in a coding assistant.

The article backs this with survey data. Teleport's 2026 State of AI in Enterprise Infrastructure Security report, built on interviews with 205 CISOs and security architects, found that organizations over-provisioning AI systems see 4.5 times more security incidents than those enforcing least privilege. In the same report, 70% said they give AI agents more access than a human doing the identical task, and 67% still use static credentials for AI systems. Both Teleport and Gravitee, whose separate survey the article also cites, sell access and security products in this space. Treat the figures as directional.

Hardening the input path

Git allows ;, $, parentheses, &, | and backticks in ref names, so git check-ref-format will not reject this payload. The agent harness has to do it. The article's list of untrusted fields covers branch names, file paths, commit messages and ticket titles. Any of them becomes command injection once it reaches a subprocess unsanitized.

The narrowest fix is to stop building shell strings. If a shell is unavoidable, allowlist the characters, reject anything that looks like an option, and quote the value:

# $BRANCH and $REPO_URL arrive from the task request; treat them as hostile
case "$BRANCH" in
  -* | *[!A-Za-z0-9._/-]*) echo "rejecting branch name" >&2; exit 1 ;;
esac
git clone --branch "$BRANCH" --single-branch "$REPO_URL" workspace

Moving the token is not enough

Moving the token out of the remote URL and into a credential helper or a git config header changes the file that holds it. Any command running as the agent's user can still read it. What limits the damage is scope and lifetime. The article's checklist:

Scope the credential to the task, not to the developer who configured the agent.
Prefer short-lived, single-use credentials over static tokens, so a theft is limited to one task.
Ask for actual visibility into what the agent's credential can do right now, as a list of repos and scopes, not a policy document.

CI has already seen this bug class

None of this is new to pipeline operators. GitHub's Actions hardening guidance has long warned against interpolating attacker-controlled values such as github.head_ref or pull request titles directly into run: scripts, and it recommends passing them through an environment variable. GitHub App installation tokens can be restricted to selected repositories and permissions, and they expire after an hour. GitLab's CI_JOB_TOKEN is valid only while its job runs. OIDC federation replaces stored cloud keys with per-job tokens.

Agent harnesses do not inherit any of that by default. The Codex sanitization bug is closed. How far the next leaked agent token reaches depends on how the agent was provisioned, and that decision belongs to whoever configured it.

npm trusted publishing finally covers dist-tags, if you ask nicely

Leo — Thu, 01 Oct 2026 10:25:20 +0000

Picture the npm maintainer who did the hard work: moved publishing to OIDC, deleted the automation token from the password manager, celebrated with coffee. Then shipped a patch and had to run npm dist-tag add from a laptop because the shiny new trusted publishing flow could push versions but not point latest at them. Awkward.

That gap closed this week. On 2026-09-30, GitHub announced that npm trusted publishing can now manage dist-tags through the same short-lived OIDC credentials it already uses to publish, instead of requiring a long-lived access token sitting somewhere unpleasant.

What the opt-in actually does

The announcement is narrow and specific. Each trusted publishing configuration on an npm package gets a new permission, labelled Allow npm dist-tag. Turn it on, and workflows authenticating with that configuration can promote a version to latest or move the next and beta pointers from CI, authenticated by the same OIDC token that would have published a version.

A few details worth pinning down:

The permission is off by default on both brand-new configurations and the ones you set up months ago. Nothing in your current setup silently gained new rights.
It is independent of direct publishing permissions. A staging-only configuration can be granted dist-tag management without also being allowed to publish, and vice versa.
Authorization triggers when an incoming OIDC token matches any configuration with the permission on.
Classic token-based dist-tag management keeps working. If you have a cron job somewhere that still uses an automation token, nothing changes for it today.

Why dist-tags are the loose brick

Publishing a version is only half of a release. The other half is pointing latest at it, because npm install your-pkg with no range resolves against latest. Whoever can rewrite latest can quietly aim an entire ecosystem at a different artifact.

That is the lateral-move path supply-chain attackers love. Steal a publish token and you can publish your-pkg@6.6.6, sure. But if you can also run npm dist-tag add your-pkg@6.6.6 latest, every unpinned install now pulls your version until a human notices. Historically that second step still needed a classic token, which meant most teams kept one around specifically for retagging, defeating the point of OIDC for publishing in the first place.

With dist-tag ops on OIDC, the "we moved to trusted publishing but kept one legacy token for tagging" footnote finally goes away, assuming you flip the box.

Turning it on without turning it loose

Two decisions sit under that single checkbox.

Which configurations get the power. The ergonomic failure mode is to tick Allow npm dist-tag on every configuration, including the one your preview workflow uses, because somebody will eventually need to retag during an incident and it is easier to pre-grant. That reproduces the problem OIDC was supposed to solve: broadly-scoped standing authority. The safer shape is a dedicated release configuration (bound to a specific workflow, a protected environment, maybe a manual approval) that is the only one allowed to retag, with publish-only configurations handling day-to-day versions.

What triggers it. Because the permission matches on the OIDC token's claims (repository, workflow, environment, and friends), what you are really doing is deciding which Actions runs are allowed to call the retag endpoint. Pin the configuration to a specific workflow file at a specific path and gate that workflow on an environment with required reviewers. The checkbox is only as strict as the token claims you check it against.

A worth-saying caveat: existing dist-tag automation that still relies on a long-lived token is not disabled by any of this. Shutting that path off is a separate decision you have to make, usually by revoking the token after you have moved the automation across. Shipping the new permission does not retire the old one for you.

How other registries and platforms handle release tags

Dist-tags are an npm concept, but "mint a short-lived credential in CI, use it to update a release pointer" is a pattern now, not a feature. A rough map:

PyPI trusted publishing was the reference implementation. It covers uploads, and effectively covers "which version pip installs by default" because PyPI picks the highest non-yanked version, with no mutable tag in the middle. Different model, same primitive: OIDC from your CI, no long-lived token sitting in a secret store.
RubyGems trusted publishing mirrors PyPI closely: gem push authenticated via OIDC from a GitHub Actions workflow bound to specific claims. Yanks and ownership changes are a separate authority there; the retag analogue is less of an issue because the "default" version is computed, not pointed-at.
GitLab CI reaches npm by federating its own ID tokens to the registry's OIDC trust. It is the better fit if your source of truth is a GitLab project and you want the publishing job's claims (project_path, ref, protected branch) to flow into the configuration you tie to the package. The new dist-tag permission applies the same way, because the gate is on npm's side.
CircleCI OIDC can do the same against npm's trust configuration, matching on CircleCI-specific claims. Honest trade-off: if your release workflow already lives on GitHub Actions, there is no real reason to add CircleCI to the path.
Jenkins does not get OIDC federation for free. Teams usually bolt on a plugin that mints an OIDC token the runner can present, or (more commonly) still ship a classic token into the agent. If you are on self-hosted Jenkins and this new permission matters to you, the honest answer is that the work is upstream of the checkbox.
Buddy is one option if you want the OIDC-emitting job and the retag step to live in the same place as the rest of your delivery pipeline, and you want environment-scoped approvals around a npm dist-tag action instead of inside a workflow file. A minimal shape:

# buddy.yml, illustrative shape only
- action: "Promote to latest"
  type: "BUILD"
  docker_image_name: "node"
  docker_image_tag: "lts"
  trigger_condition: "ON_EVERY_PUSH"
  trigger_conditions:
    - trigger_condition: "VAR_IS"
      trigger_variable_key: "GIT_REF"
      trigger_variable_value: "refs/tags/v*"
  execute_commands:
    - "npm whoami"
    - "npm dist-tag add $PACKAGE@$VERSION latest"

The point of listing six options is that none of them is "the best" in the abstract. Which one you pick is a function of where your source of truth already lives, how your approval model is shaped, and how much appetite you have for owning a plugin to make OIDC work.

The uncomfortable bit

The press release reads like a win, and it is. One less long-lived token in one less secret store is one less thing to rotate and one less thing to steal. But opt-in defaults mean the ecosystem benefit lands when maintainers actually open the settings panel and tick the box, not on 2026-09-30. Until then, every package that previously held an automation token for tagging is still holding it, OIDC or not.

Go turn it on. Then go delete the token.

GitLab ships critical patch across 19.4, 19.3 and 19.2

Leo — Tue, 29 Sep 2026 10:24:52 +0000

What shipped

GitLab pushed a critical patch release on 23 September covering three active branches at once: 19.4.1, 19.3.3 and 19.2.7. The release notes on docs.gitlab.com bundle fixes rated from Critical through Low, and the maintainers strongly recommend that self-managed installations upgrade. Two of the disclosed issues carry the Critical label. Several fixes are Enterprise Edition only; most apply to both CE and EE.

The operationally awkward detail is the age of the affected code. A couple of the vulnerabilities reach back to the 13.x and 15.x lines, meaning any instance sitting on an older LTS-style branch is exposed to bugs that predate the current major by years. The release notes offer no partial mitigation. The fix is the upgrade.

What it costs to absorb

Multi-node instances can take the patch with zero downtime by rolling nodes through the standard update procedure. Single-node installs cannot: the release notes state the patch causes downtime, so a change window is required. That one sentence is the whole planning story for most teams running GitLab on a single host, and it decides whether the upgrade happens tonight or waits for the next scheduled window.

For pipeline owners the read is narrower. A GitLab upgrade window locks the runner fleet's control plane, so long-running deploys, scheduled jobs and any merge trains queued against that instance need to drain or be paused. Critical-rated CVEs shorten the argument between the security team's clock and on-call's change freeze. Operators still on 19.2 or 19.3 have a second question to answer before booking the outage: whether to take just the branch patch, or ride the upgrade all the way to 19.4.1 while the window is already open.

The right fix for double-tap zoom is one CSS line, not a viewport lock

Leo — Sat, 26 Sep 2026 16:10:08 +0000

There is a category of "accessibility fix" that fixes nothing and locks people out. Disabling zoom on the whole page to stop one button from misbehaving is the classic example. If a user rapid-taps a control on your radio player, your podcast list, your carousel of station cards, and the page yanks itself larger under their thumb, the answer is not to take zoom away from everyone who needs it. The answer is to tell that one button to stop treating a fast second tap as a gesture.

Andy Bell ran into this on a web radio player he was trying on his phone. Flicking rapidly through stations to find one on air, iOS Safari read the fast successive taps as its double-tap-to-zoom gesture, and the page zoomed in and out under his fingers. The write-up is short. The fix is shorter.

The reflex fix costs more than it saves

You have seen the workaround before. Something in the UI misbehaves under fast taps, and someone reaches for the viewport meta tag:

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

That kills every zoom gesture on the whole page. Not just the double-tap on the button. Pinch, too. A user with low vision cannot enlarge the text. A user of a magnifier extension has nothing left to work with. Adding maximum-scale=1.0, user-scalable=no to the viewport is called out in Andy's write-up as a WCAG violation, and it has been called out as one for as long as mobile Safari has shipped. The bug is fixed; the page is broken for the people who most need it to work.

If your accessibility patch takes an ability away from every visitor to stop one gesture on one control, you have shipped a regression.

Scope the opt-out to the control

The tool Andy reaches for is touch-action, applied directly to the button:

button {
  touch-action: manipulation;
}

That is the whole change. Per MDN, touch-action: manipulation is an alias for pan-x pan-y pinch-zoom. The browser keeps single-finger panning. It keeps two-finger pinch to zoom. What it drops is the browser's own set of extra gestures, most notably double-tap to zoom. A rapid second tap on a control that carries manipulation fires as a second click, not as a zoom.

There is a small side benefit. touch-action: manipulation also removes the click-event delay that browsers historically inserted after a tap so they could disambiguate a first tap from an incoming double tap. On a control that has opted out of the second-tap gesture, there is nothing to wait for.

Two things to notice about this fix, both of them accessibility properties in their own right:

It only affects the element you put it on. The rest of the page, headings and body copy and the whole reading surface, still zooms normally.
It targets the browser's page-level zoom gestures on that one element, not the ability to zoom itself. Pinch stays.

That is what an opt-out should look like: applied to the control that has a reason to opt out, and no wider.

For your next PR

If a control misfires on fast taps, put touch-action: manipulation on that control, not on the page.
Do not touch the viewport meta to fix a per-button problem. maximum-scale=1.0 and user-scalable=no are the anti-pattern here, not the escape hatch.
Leave pinch zoom alone. It is a feature for the people who need it to read your interface, not a defect for you to close.
If a viewport lock is already sitting in a shared template somewhere, this is a good week to open the PR that pulls it.

GitLab's per-user email token can push code and trigger pipelines

Leo — Sat, 26 Sep 2026 10:24:27 +0000

Every GitLab user carries a credential most of them have never looked at. It sits inside a per-project email address, it can push code and run pipelines, and it does not expire. Aikido Security researcher Joe Leon disclosed this week, in reporting on DevOps.com, that if that address leaks an attacker gets a fine-grained personal access token in convenient email form.

The mechanic, per Leon's writeup: GitLab lets you create issues and merge requests by emailing a project. The token inside those private addresses is the same one across every project the user can reach. Change the suffix from "-issue" to "-merge-request", attach a .patch file, and you are submitting code as that user. Which means CI/CD runs. Which means CI_JOB_TOKEN. Which means whatever else that job can touch.

What the token actually unlocks

Leon lists the reachable surface as pushing patches, kicking off CI/CD pipelines, pulling private source, reading CI/CD variables and secrets, and pivoting to other GitLab resources via CI_JOB_TOKEN. Anywhere the account owner has access, the emailed token has access. GitLab's own documentation, quoted in the article, calls it "essentially a fine-grained personal access token with significant access to your GitLab projects." Read that sentence twice.

GitLab's response, and yours

GitLab has not turned the feature off. Aikido's HackerOne report in May was closed as intended behavior. A confidential issue followed in June. On July 28 GitLab opened a merge request updating the docs so the capability of the token is described more plainly. The interface got a clarification pass. That is the fix.

The user-side mitigation is one click: reset the token in personal access token settings and every previously issued project address dies with it. Do that on any account whose email has ever appeared in a leak, a screenshot, a stale CI log or a support ticket. Rotate on a schedule if you can stomach the churn.

A long-lived credential that grants pipeline write access, transmitted over email by design. Working as intended.

Overlap detection lands in CSS with anchors and a shared timeline

Leo — Fri, 25 Sep 2026 16:08:28 +0000

Two elements share a row. A big word mark on the left, a section on the right. Resize the window and at some width they crash into each other. You know the shape of the fix. A ResizeObserver, a class toggle, some hand-drawn threshold in JavaScript. On ishadeed.com, Ahmad Shadeed argues you can do the whole thing in CSS.

The move has three parts, and each one leans on a modern primitive.

Anchor two elements, then measure the gap between them

Start with anchor positioning. The decoration gets anchor-name: --line. The section that might collide with it gets anchor-name: --section. That is the opening move. Two names, so the rest of the stylesheet can point at these boxes by handle rather than by DOM position.

Now the trick. A third element, called .measure, is positioned to fill the horizontal space between the two anchors:

.measure {
  left: anchor(--line right);
  right: anchor(--section left);
}

Read that literally. Its left edge sits at the right edge of the line. Its right edge sits at the left edge of the section. When the layout has room, .measure has width. When the two collide, that width collapses to zero. You have turned overlap into a geometry problem you can point CSS at.

Turn size changes into animation progress

Anchor positioning gets the measurement. CSS still has to react to it. That is the scroll-driven animations piece.

The source wires one element with scroll-timeline: --box and drives another with animation-timeline: --box. Once that link exists, the second element's animation is bound to the first element's scroll progress. Changing what is happening on one box becomes progress on somebody else's animation.

That is the small, boring miracle here. Two mechanisms designed for different jobs, anchor positions and scroll timelines, meet in the middle and become an overlap listener.

Why timeline-scope is the piece that makes it composable

There is a catch, and it is the reason the article exists. A named scroll-timeline is scoped to the element that defines it. Only that element and its descendants can see the name. If the thing you want to animate is a sibling, or lives higher up the tree, the name is invisible to it.

timeline-scope fixes that. Put it on a common ancestor and the named scroll-timeline is lifted up to that ancestor's scope, where any descendant can consume it. That is what makes the pattern actually usable. You can put the measurement inside the layout and wire the reaction, hiding the decoration or swapping a color, anywhere in the subtree.

Without timeline-scope, you would be architecturally stuck. With it, the pieces snap together.

What it changes on your next layout

A caveat straight from the source: the demos need a browser that supports both scroll-driven animations and CSS anchor positioning. This is not a technique you can hand every visitor tomorrow.

The design question is the bigger one. For years, "react to layout" meant reaching for ResizeObserver and IntersectionObserver. Those APIs are fine, but they push layout-aware behaviour into JavaScript, where it competes with everything else on the main thread. The pattern in this article does not. The measurement is a positioned element. The reaction is an animation timeline. The wiring is a scoped name.

The interesting next question is not "when does this ship everywhere" — it is what else you have been solving in JavaScript that fits this same shape. Collision. Gap thresholds. Container state that is really about geometry, not media features. Anywhere you were listening to resize to change a class, there is now a CSS-native path worth trying first.

Safari Technology Preview 253 lets container queries branch on sibling-index() and frees style-originated scroll timelines

Leo — Thu, 24 Sep 2026 16:07:53 +0000

I opened the notes this morning, and the first item made me stop scrolling. sibling-index() and sibling-count() inside a @container condition. That's a small change on paper and a real shift in what container queries can answer.

Safari Technology Preview 253 is out for macOS Golden Gate and macOS Tahoe, and covers WebKit changes 320113@main through 321067@main. Preview channel, one engine. The release does not claim Baseline for anything below, and I won't extrapolate one.

The change that reframes container queries

Per the release, @container conditions can now use sibling-index() and sibling-count() — change 320493@main. Container queries have always answered "how wide is my container", "how tall is my container". They now answer a different kind of question: "where am I in the list I belong to, and how long is that list".

That's a category shift. Position among peers used to be an :nth-child job on the child selector side of the cascade, or a script that walked the DOM and set data attributes. Neither approach fed a container query. Now the condition itself can carry that fact, and the rule body can respond to it.

The release lists the change and the WebKit revision. It does not print a full example. I am not going to invent one — if you are trying it in STP tonight, the shape you want to try is a @container block whose condition tests one of the two functions, and let the parser tell you what it accepts.

The scroll-timeline scope, opened up

Style-originated scroll timelines now match globally, per change 320183@main. Read that carefully: they can be defined outside the target's ancestor hierarchy, or outside an element that carries a timeline-scope property. Before this change, a timeline had to sit somewhere the animated element could see through the tree. That constraint was the reason authors were reaching for timeline-scope in the first place, to hoist visibility up to a common ancestor.

The release frames the change as "match globally". If you had a scroll-driven animation working only because you had rearranged the DOM to put the timeline in the right ancestor, that plumbing can start coming out.

The rest of the CSS and OM surface

Two smaller items round out the release:

CSSContainerRule.conditions is now supported (change 320762@main). The condition text of a @container rule is readable off the CSSOM, so tooling that inspects stylesheets can ask a rule for its own condition instead of parsing selectors by hand.
The ViewTimeline constructor now correctly requires a subject parameter (change 320969@main). If your script was constructing a ViewTimeline without one and getting away with it, that call will need to change. A tightening of the JavaScript API to match the specification, not a new capability.

An accessibility fix worth reading twice

Change 320424@main is a VoiceOver correction. When aria-keyshortcuts values contain Meta or Alt, VoiceOver was announcing those tokens literally, instead of the macOS terminology Command and Option. Users heard "Meta" for the key labelled Command on the keyboard in front of them.

That's the kind of quiet correctness fix that only surfaces when you sit with a screen reader and listen. If you author custom shortcuts on interactive components, this is one to re-run through VoiceOver once the fix reaches a channel you can test against.

What I'm watching next

Two things. First, whether other engines pick up sibling-index() and sibling-count() in @container conditions — cross-engine parity is what turns a preview curiosity into something you can lean on in a design system. Second, what authors actually do with style-originated timelines now that they escape the ancestor hierarchy: the interesting demos will be the ones that would have needed timeline-scope gymnastics before, and now do not.

Nothing here has a Baseline claim. STP is what STP has always been: try the syntax, keep the fallback path intact, watch the other engines.

The CrowdSec leak is a lesson in the OAuth token you forgot to revoke

Leo — Thu, 24 Sep 2026 10:25:17 +0000

Somewhere in your GitHub organization, a former employee still holds an active OAuth authorization for your private repositories. You just have not audited the list this year. And when the next npm supply-chain event fires, that grant is what walks out of a poisoned build and clones your source.

This is not hypothetical. DevOps.com reported on September 24 that CrowdSec, the French threat-intelligence outfit, had source code stolen from about 170 of its private GitHub repositories after an OAuth token tied to a former employee's GitHub account was scraped by attackers who had first compromised the TanStack npm packages. The attacker group calling itself TeamPCP cloned the archive in a window the report clocks at roughly nine minutes. The code eventually surfaced on a dark-web leak forum months later.

The chain, one step at a time

Walk the sequence end to end, because the interesting failure is not where you might expect.

Step one, per the report: in May, TeamPCP pushed malicious artifacts into TanStack's npm packages using a self-propagating worm the writeup labels "Mini Shai-Hulud." The worm's job was not to sabotage your build. Its job was to sit inside your build and rifle through the environment for credentials and tokens.

Step two: one of the developers whose install pulled a poisoned TanStack package happened to be a former CrowdSec employee. Their personal GitHub account still carried an OAuth authorization for CrowdSec's organization, with read access to private repositories. The worm scooped that token alongside everything else in reach.

Step three: attackers cloned. About 170 private repositories from a larger set of public and private ones, downloaded in a nine-minute burst that the report attributes to scripts rather than a human at a keyboard. CrowdSec revoked the former employee's access days later. The archive was already elsewhere, and it turned up on a leak forum in September.

The OAuth-app ledger nobody audits

Read that chain again. The npm worm is the loud, interesting part. The pivot into CrowdSec's private repositories was almost boring: it used an OAuth grant nobody had reviewed since the employee's exit interview.

An OAuth token issued to a personal GitHub account is a bearer credential. It does not know the employee left. It does not care that HR closed the ticket on their last working day. It sits in your organization's list of authorized OAuth apps until someone revokes it explicitly or the third-party app is uninstalled, and a repo scope covers every private repository the account had access to on the day the grant was signed.

This is the CI/CD security question that hides in plain sight. Every team drills SSO offboarding. Fewer teams script OAuth-app offboarding. Almost nobody drills a scenario where a third party's build is the compromise and the pivot vector is a token they issued three quarters earlier for a plugin nobody uses anymore.

What to actually check this week

Some of these are dull. Do them anyway.

Export the list of OAuth apps authorized in your GitHub organization, then cross-reference the user accounts against current employees. Every mismatch is a suspect.
Enforce OAuth-app approval at the organization level so an individual contributor cannot silently authorize a new tool against repo scope.
Where the tooling supports it, prefer GitHub Apps with fine-grained repository permissions over user-scoped OAuth apps. GitHub Apps live at the organization level and survive the employee, cleanly.
Rotate anything a poisoned CI or laptop build could have touched: .npmrc tokens, cached cloud credentials, SSH keys copied into agent workspaces, personal access tokens sitting in shell dotfiles.
Treat every ecosystem-scale npm compromise as a credential-rotation event for anyone whose laptop or pipeline installed that package family in the affected window. Not only the developer who noticed something odd. Everyone.

Where the industry is heading

Some ecosystems are sanding this problem down. GitHub's own push toward fine-grained personal access tokens and short-lived OIDC-brokered credentials in Actions targets the same shape: a token you cannot forget, because it expired ninety minutes after the workflow finished. GitLab and Bitbucket have moved along the same axis with workload-identity federation into the major cloud providers. The pattern is consistent across vendors. Replace long-lived bearer tokens with something the pipeline mints on demand and the identity provider revokes on its own timer.

None of that retires the OAuth-app grants sitting in your organization tonight. That surface predates the newer models. It is nobody's favourite thing to review, which is exactly why it is where the attackers went.

The kicker

Your offboarding checklist ends where your OAuth-app inventory begins. Go look at it. You will not like what you find.

Chrome 154 ships responsively-sized iframes with a two-side opt-in

Leo — Wed, 23 Sep 2026 16:08:25 +0000

I wired this into a comment widget this morning and the handshake is exactly what the writeup promised. Chrome 154 gives <iframe> a new CSS property called frame-sizing, and the embedded page has one job: drop a <meta name="responsive-embedded-sizing"> tag in its <head>. The outer page and the embed agree, the frame takes on the size of its content, and nothing has to postMessage a pixel count across the origin boundary. Per Bram's post dated 23 September 2026, only Chromium ships it. Firefox and Safari have no support and no tracking bugs yet.

The two sides of the handshake

frame-sizing goes on the <iframe> and accepts auto, content-height, content-width, plus logical-property variants. That is the embedder's request: size yourself to your content's intrinsic height, width, or both. On its own it does nothing. The embedded page has to opt in with a meta tag:

<meta name="responsive-embedded-sizing" content="allow-origins=*">

The allow-origins value can be a list of origins instead of *, which is how the embed picks who is allowed to receive its size information. If your comment widget is dropped into twenty sites but you only want two of them to auto-size, that is the knob.

The smallest working wire-up

Outer page:

<iframe src="https://comments.example/thread/42"
        style="frame-sizing: auto"></iframe>

Inside the embed:

<meta name="responsive-embedded-sizing" content="allow-origins=*">

That is it. No ResizeObserver. No script.

Telling the parent you grew

Content shifts after load. Someone opens a reply, an image finishes decoding, a "load more" runs. When that happens the embedded document calls window.requestResize() and the outer page picks up the new size through the same channel. One method call replaces the postMessage-plus-parseInt-plus-parent-style-write recipe most embeds carry around today.

The cross-browser reality

Here is the part I have to keep honest. Per the browser-support table in Bram's post on 23 September, frame-sizing and responsive-embedded-sizing are Chromium-only right now. Firefox has no support and no tracking bug. Safari has no support and no tracking bug. So this is progressive enhancement in the strictest sense: shipping it today upgrades one engine and leaves the others exactly where they were. If you already keep a postMessage fallback for embed heights, keep it. If you do not, the frame renders at whatever height and width you set on it, same as always.

What I am watching next

Whether Gecko and WebKit file tracking bugs at all, and how allow-origins behaves in the field. A cross-origin size channel is exactly the kind of surface that tightens as embedders test it against ad frames and third-party widgets. I also want to see whether the property picks up more values once authors put pressure on the shape.

The Codex sandbox escapes prove your agent's blast radius is your laptop

Leo — Tue, 22 Sep 2026 10:24:56 +0000

Your coding agent is running untrusted patches inside a sandbox on the same laptop that holds your SSH keys, your cloud tokens, your kubeconfig, and the GitHub credentials that push signed commits into production. Take a moment with that mental image. Comfortable? Good.

On September 15, 2026, Accomplish AI published the technical write-up of two sandbox escapes in OpenAI Codex. Researcher Oren Yomtov named them Heapjack and Overpatch. Both let code jump out of the Codex sandbox and run on the developer host with no approval prompt and nothing on screen. Reported to OpenAI on August 12, patched within eight days. Fast triage, and OpenAI earned that credit. The uncomfortable part is that the shape of the bug is going to keep happening, because the sandbox lives inside the thing it is supposed to contain.

The mechanics, kept to what the disclosure says

Heapjack and Overpatch had different root causes, per Accomplish's writeup, but the same outcome: arbitrary code executing on the developer's machine outside the approval flow that Codex normally shows for shell commands, network calls and file writes. No dialog fired. No log line surfaced. A user watching the agent work would have seen the same interface they always see, while a payload from a fetched dependency or a poisoned test fixture was already running as them.

Two independent escapes, one system, one review cycle. That is the number that matters. Not because OpenAI is uniquely careless (they patched within a week and a day), but because the sandbox model everyone in this space uses is a probabilistic bet against a determined attacker and a large surface area.

Why "on the same machine" is the wrong trust boundary

Look at what a coding agent inherits when it runs on your laptop:

The SSH keys that push to your git host.
The keychain entries and short-lived tokens that open pull requests, merge changes and kick off CI runs.
Cloud credentials cached under ~/.aws, ~/.config/gcloud, ~/.kube.
npm, PyPI and container-registry publish tokens.
Whatever .envrc you loaded three sessions ago and forgot.

A sandbox escape in this context is not "the agent ran a stray command." It is "attacker-controlled code inherited your full developer identity, including the credentials that sign commits and trigger production deployments." That is a supply-chain path that starts on the laptop and ends in the release pipeline, wearing a legitimate signature the whole way.

GitHub's 2026 Actions security roadmap already cites tj-actions/changed-files, Nx and trivy-action as recent pipeline-targeting incidents. Those all travelled through the CI system itself. Heapjack and Overpatch open a second lane, one that skips CI entirely and compromises the human whose keys CI trusts. If your threat model stops at the runner, you now have a gap.

Approaches that move the blast radius somewhere less painful

There is no free lunch here, but there are architectures that put the compromise domain somewhere other than your developer identity:

Container isolation wraps the agent in a namespace boundary. It shares the kernel, and any workspace mount usually punches a convenience hole straight back through the boundary. It stops the trivial cases and nothing more.
microVM sandboxes give the agent its own kernel. This is the direction production CI runners have moved for the same reason: strong isolation cheap enough to spin up per task.
Remote execution moves the whole runtime off the developer machine. The agent runs in a hosted workspace reached over an API, so an escape reaches a stateless VM the vendor recycles, not your keyring.

Each of these costs something. Remote execution loses low-latency filesystem work. microVMs cost RAM and start-up time. Containers still hand you a shared kernel. Pick your poison, but pick one that fails into a domain you can rotate cheaply.

What to change on Monday

You cannot wait for every agent vendor to redesign their sandbox. In the meantime:

Assume any coding agent on your laptop can eventually reach anything your shell can. Move long-lived tokens out of the environment and into a keychain that requires per-use approval.
Prefer agents that run in a remote or containerised workspace when the task allows it. Accept the latency.
Rotate credentials after any agent session that used shell tools or fetched network content. Yes, all of them.
Push CI toward OIDC-brokered short-lived credentials, so a stolen laptop token cannot pivot into production.

The kicker

Every agent vendor will tell you the sandbox is safe. Right up until the writeup goes live and the patch note ships. Trust the boundary, never the brochure.

Container queries observe the component, not the viewport

Leo — Sat, 19 Sep 2026 16:08:17 +0000

Drop a card component into a two-column layout. In the wide column it lays out as a row: image left, copy right. Move the same card into a 320px sidebar and it still tries to be a row, because its breakpoint was written against the viewport, not the box it now lives in. That is the pattern Victor Ayomipo, writing in Smashing Magazine on 16 September, is trying to get you to stop shipping.

Where each query lives

Media queries answer the browser. Container queries answer the box.

Ayomipo frames it as "macro" vs "micro" layout. A media query asks the viewport how wide the page is. A container query asks a specific ancestor element how wide it is. Reuse the same breakpoints across both and the component reads the wrong signal.

The State of CSS numbers he cites explain why the mismatch keeps happening: 86% of developers know container queries exist, and 41.4% actually use them. Browser support sits at roughly 94% (caniuse.com), so the gap is not the engines. It's the habit of copying media-query shapes into new syntax.

The two-line wiring

The minimum shown in the source to make a card respond to its own width:

.card-wrapper {
  container-name: card;
  container-type: inline-size;
}

@container card (min-width: 450px) {
  .card {
    display: flex;
    flex-direction: row;
  }
}

container-type: inline-size gives the wrapper a size a descendant can query. container-name labels it. Then @container card (...) reads that wrapper's inline size, not the viewport. Drop the card in a 300px rail: the row layout stays off. Drop it in a 600px column: it flips. Same component, two contexts.

One rule to internalise, per the article: you cannot query the element you are styling. The component and its container have to be different nodes, or the layout goes into a loop. That is the reason for the wrapper.

Container units, same idea

Container units are the other half. Ayomipo's typography example:

.card-title {
  font-size: clamp(1rem, .5rem + 3cqi, 2rem);
}

cqi is 1% of the container's inline size. Wired to a container-type: inline-size ancestor, clamp() gives the title a floor, a ceiling, and a smooth ramp between them driven by the box rather than the viewport. The card grows and shrinks with its column. No media-query stack, no per-breakpoint font sizes.

The rough edges

The article walks through a flex-wrap detection pattern for a card grid: flex items sized flex: 1 1 390px are each given container-type: inline-size, then an @container (min-width: 600px) rule flips a card from column to row once it stops sharing its row with siblings. The card notices when it is alone. The viewport is not involved.

Ayomipo also flags the sharp corners. Querying block size can collapse a layout when the container has no explicit height. Custom-property values do not work inside a container-query condition, so a shared --breakpoint variable is out. And the wrapper element is real DOM; a component still cannot query itself.

What to try next

Pick one component on your current project that reads viewport width — a card, a media object, a summary tile. Wrap it, set container-type: inline-size on the wrapper, and rewrite its breakpoints as @container rules with cqi for the type ramp. Drop it in three contexts on the same page. If it renders the same layout in a 300px rail and a 900px column, the breakpoints are still viewport-shaped. Kevin Powell, quoted from a SmashingConf Amsterdam 2026 talk, called container-query adoption "terrible" for exactly that reason.