[BUG] Sandboxed `mktemp -d` fails on macOS (ignores `$TMPDIR`); the empty variable made `rm -rf "$T"` run against the working directory with no critical-path prompt

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

This report describes one compound failure chain: inside the macOS sandbox, a template-less mktemp -d fails and leaves the scratch-directory variable empty; cd "" && pwd -P then resolves that variable to the working directory; and the resulting bare rm -rf "$VAR" is not treated as a critical-path removal. A Workflow subagent's scratch cleanup therefore ran rm -rf against the working directory, leaving roughly three quarters of the top-level directories under it stripped or non-functional (see Impact). The two links in the chain:

1. macOS sandbox + mktemp -d. $TMPDIR (/tmp/claude-<uid>) is writable inside the sandbox, but BSD mktemp -d with no template does not honour $TMPDIR: per man mktemp, with no arguments it "behaves as if -t tmp was supplied", and -t uses _CS_DARWIN_USER_TEMP_DIR (/var/folders/<xx>/<hash>/T/) first, TMPDIR only as a fallback. That location is outside the documented default write set, and the call failed with Operation not permitted, printed nothing to stdout, and left the variable empty (the denial is consistent with that boundary; the seatbelt profile was not inspected — see Not verified). The sandboxing docs say Claude Code "sets $TMPDIR to this directory for sandboxed commands, so tools that write temporary files work without extra configuration"; on macOS a template-less mktemp -d is a counterexample.
2. A bare rm -rf "$VAR" whose value became the cwd at runtime was not treated as a critical-path removal. T=$(cd "$T" && pwd -P) with T="" is a successful no-op cd followed by pwd -P, so T became /Users/<user>/code/github.com. The docs list "Your working directory and its parents" as a critical path that prompts even in bypassPermissions, and already treat rm -rf "$DIR"/* as critical "because the command becomes a removal from the filesystem root when the variable is empty". Here the variable was empty too, but cd "" + pwd -P turned it into the cwd, and the documented critical-path list names only "a glob or trailing slash directly under a shell variable, such as rm -rf "$DIR"/*" — a bare rm -rf "$VAR" is not on it. The docs state that "Bash rules match the whole command text" (permissions → Tool-specific permission rules → Bash), i.e. matching is over the command text before execution, so it cannot see that T had become the cwd at runtime. No critical-path prompt is recorded, and the call's 120.04 s elapsed time equals the default timeout exactly, leaving no room for a prompt wait.

Two known issues sit alongside this chain and are not what is reported here. set -e is ineffective inside the Bash tool (#90611), so the script's set -euo pipefail did not abort after the failed assignment. And a content-scoped ask rule did not prompt for this sandboxed command — already tracked as #76850 (bot-closed as duplicate of #6527; #42797 closed as completed 2026-08-16, which asks for current-version recurrences to be reported with the exact rule, command, version and claude doctor output).

Failure chain (offsets from the workflow launch, T+0)

Exact UTC timestamps, the session id, and claude doctor output can be supplied privately on request.

1. T+0 Parent session launches a Workflow run. The subagent's task prompt instructed read-only operation, forbade writes outside a designated scratch area, and confined test fixtures to $TMPDIR. Neither the prompt nor the orchestrating script contains mktemp or rm -rf; the fixture pattern below was the agent's own choice.

1. T+6m23s The subagent issues a Bash tool call (a filesystem-behaviour probe; input keys command and description only — no timeout, no dangerouslyDisableSandbox). Full command, except that an unused scratchpad-path assignment is omitted:

<details><summary>Command text</summary>

``bash
set -euo pipefail
echo "TMPDIR=$TMPDIR"
python3 - <<'PY'
import os, stat, tempfile, ctypes
d = tempfile.mkdtemp()
d = os.path.realpath(d)
p = os.path.join(d, "f")
open(p, "wb").write(b"x"*10)
os.chmod(p, 0o644)
fd = os.open(p, os.O_RDONLY | os.O_NOFOLLOW)
print("opened O_RDONLY")
try:
os.fchmod(fd, 0o400); print("fchmod on O_RDONLY fd: OK")
except OSError as e:
print("fchmod on O_RDONLY fd: FAIL", e)
try:
os.fsync(fd); print("fsync on O_RDONLY file fd: OK")
except OSError as e:
print("fsync on O_RDONLY file fd: FAIL", e)
dfd = os.open(d, os.O_RDONLY | os.O_DIRECTORY | os.O_NOFOLLOW)
try:
os.fsync(dfd); print("fsync on O_DIRECTORY fd: OK")
except OSError as e:
print("fsync on O_DIRECTORY fd: FAIL", e)
libc = ctypes.CDLL(None, use_errno=True)
try:
fn = libc.renameatx_np; print("renameatx_np symbol: OK")
except AttributeError as e:
print("renameatx_np symbol: FAIL", e)
os.close(fd); os.close(dfd)
print("python:", __import__("sys").version)
PY
echo "== stat format checks =="
T=$(mktemp -d); T=$(cd "$T" && pwd -P)
mkdir -m 700 "$T/d700"; : > "$T/f400"; chmod 400 "$T/f400"; : > "$T/f600"; chmod 600 "$T/f600"
stat -f '%N %Lp' "$T/d700" "$T/f400" "$T/f600"
rm -rf "$T"
jq --version
``
</details>

Note: an unused scratchpad variable was assigned and is omitted here; the bare mktemp -d has no template and no $TMPDIR prefix.

1. mktemp -d failed under the sandbox, on a path that was not $TMPDIR. Tool output, verbatim except for the redacted uid and per-user path components and the elided Python lines (...):

``
TMPDIR=/tmp/claude-<uid>
...
== stat format checks ==
mktemp: mkdtemp failed on /var/folders/<xx>/<hash>/T/tmp.XXXXXXXXXX: Operation not permitted
``

mktemp printed to stderr, wrote nothing to stdout, and T became the empty string. The sandboxing docs define the default write set as the working directory, additionalDirectories, and "the session temp directory that $TMPDIR points to"; /var/folders/<xx>/<hash>/T is none of these, so the denial is consistent with the documented boundary (inferred from the EPERM; the seatbelt profile itself was not inspected). $TMPDIR was writable: repro A below prints Python's tempfile.mkdtemp() path under $TMPDIR, and in the incident command the same call succeeded (its path was not printed).

1. set -e (errexit) did not abort after the failed assignment. Reproduced write-free in the same Bash tool: set -e followed by false followed by echo REACHED prints REACHED, with [[ -o errexit ]] reporting the option set; the same three lines in a fresh zsh -c or bash -c abort at false. Consistent with #90611 (command run via eval as a non-final &&/|| list member; the incident output carries zsh-style (eval):N: prefixes). set -u does not apply (T is set, empty, not unset) and pipefail is not exercised by this line; only errexit was shown ineffective.

1. T=$(cd "$T" && pwd -P) resolved to the working directory. cd "" succeeds with status 0 and stays in the cwd in both zsh 5.9 and bash (tested). The next three output lines prove it:

``
/Users/<user>/code/github.com/d700 700
/Users/<user>/code/github.com/f400 400
/Users/<user>/code/github.com/f600 600
``

1. rm -rf "$T" ran against the working directory. Output continues immediately with lines of the form rm: /Users/<user>/code/github.com/<owner>/<repo>/.git/config: Operation not permitted. In the ~10 KB of output preserved before truncation there are dozens of rm: …: Operation not permitted lines across several repositories — all of them under <repo>/.git/hooks/* or for <repo>/.git/config — followed by Directory not empty for the enclosing directories. The transcript notes [20044 characters truncated], so the full error list is not recorded.

1. T+8m23s The tool result arrives with is_error: true, beginning Exit code 143\nCommand timed out after 2m 0s. Elapsed 120.04 s, i.e. exactly the default 2-minute Bash timeout.

1. No gate is recorded, and the timing leaves no room for one. The tool_use block is {type, id, name, input, caller:{type:"direct"}} and is immediately followed by its tool_result; no permission, classifier, ask, or hook record referencing this tool-use id exists in the subagent or parent transcript, and the 120.04 s between issue and result equals the default timeout, so no prompt wait preceded execution.

1. T+8m33s The subagent's next message: "I made a serious error — mktemp -d failed, leaving $T empty, and my cleanup rm -rf ran against the working directory." Its final output described recursively deleting most of the working directory and its git object stores.

1. T+30m The user notices most local repositories are empty.

What Should Happen?

• A sandboxed mktemp -d on macOS should create its directory under $TMPDIR (or the sandbox should allow the Darwin per-user temp dir), so the documented $TMPDIR guarantee holds for the standard temp-directory tool.
• A bare rm -rf "$VAR" (no glob, no trailing slash) whose variable is unassigned, or is assigned in the same command from a command substitution, should be treated as a possible critical-path removal and take the documented flow (prompt in default/acceptEdits/bypassPermissions, classifier in auto) — extending the same empty-variable reasoning the docs already apply to rm -rf "$DIR"/*. A static check cannot see the runtime value, which is exactly why the command form should be enough.

Error Messages/Logs

Exit code 143
Command timed out after 2m 0s
TMPDIR=/tmp/claude-<uid>
...
== stat format checks ==
mktemp: mkdtemp failed on /var/folders/<xx>/<hash>/T/tmp.XXXXXXXXXX: Operation not permitted
/Users/<user>/code/github.com/d700 700
/Users/<user>/code/github.com/f400 400
/Users/<user>/code/github.com/f600 600
rm: /Users/<user>/code/github.com/<owner>/<repo>/.git/config: Operation not permitted
rm: /Users/<user>/code/github.com/<owner>/<repo>/.git/hooks/commit-msg.sample: Operation not permitted
...
rm: /Users/<user>/code/github.com/<owner>/<repo>/.git/hooks: Directory not empty
rm: /Users/<user>/code/github.com/<owner>/<repo>/.git: Directory not empty
rm: /Users/<user>/code/github.com/<owner>/<repo>: Directory not empty
... [20044 characters truncated] ...

Steps to Reproduce

Run each block as a single Bash tool call, sandbox enabled, on macOS.

A. mktemp -d ignores $TMPDIR inside the sandbox (harmless):

echo "TMPDIR=$TMPDIR"
python3 -c 'import tempfile; print("python mkdtemp:", tempfile.mkdtemp())'
D=$(mktemp -d); echo "mktemp exit=$? stdout=[$D]"

Observed on the affected host (2.1.255): Python creates a dir under $TMPDIR; mktemp prints mktemp: mkdtemp failed on /var/folders/<xx>/<hash>/T/tmp.XXXXXXXXXX: Operation not permitted, exit 1, empty stdout.

B. The empty-variable chain (no deletion; echo guards the rm):

set -euo pipefail
R="$TMPDIR/rmrf-repro"; mkdir -p "$R/victim"; cd "$R"
T=$(false)                          # stands in for the failed mktemp
echo "after failing assignment: T=[$T]"   # expected under set -e: never reached; observed: reached, T=[]
T=$(cd "$T" && pwd -P)
echo "T now = [$T]"                 # observed: the cwd ($R)
echo WOULD RUN: rm -rf "$T"         # would delete the cwd and everything in it

Reproduced three times independently with echo in place of rm; one run also executed the real rm -rf "$T" against a throwaway fixture under $TMPDIR and confirmed it deletes the cwd. The same probe was run later in a separate session on the same host (not the incident session; that later session's records carry permissionMode: auto), sandboxed with autoAllowBashIfSandboxed: true: the multiline rm -rf on a $TMPDIR fixture returned in about a second; no permission decision is recorded either way (see Not verified). A content-scoped ask rule not prompting for a sandboxed command is the known #76850/#6527 symptom and is not argued here.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.255 (Claude Code, embedded in Claude Desktop 1.40609.1)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Environment

| Item | Value (observed) |
|---|---|
| Claude Code version | 2.1.255, embedded in the current Claude Desktop build (1.40609.1). Both the incident and reproductions A and B are on this version. |
| Account / backend | Claude subscription signed in through Claude Desktop; no API key is configured (ANTHROPIC_API_KEY and ANTHROPIC_AUTH_TOKEN unset, no apiKeyHelper). Not AWS Bedrock and not Google Vertex AI — the form's "Platform: Anthropic API" is selected to mean first-party Anthropic rather than an API-key deployment. |
| Entrypoint | claude-desktop |
| OS | macOS, Darwin 25.5.0 |
| Shell used by the Bash tool | zsh 5.9 ($0=/bin/zsh, ZSH_VERSION=5.9, probed post-incident on the same host; the incident output carries zsh-style (eval):N: prefixes) |
| Claude model | claude-opus-5, effort xhigh |
| Agent | Workflow-tool subagent: agentType: "workflow-subagent", spawnDepth: 1, isSidechain: true, cwd: /Users/<user>/code/github.com |
| Permission mode | Every permissionMode record in the parent session carries bypassPermissions. User settings.json has "defaultMode": "auto"; how the session came to run in bypassPermissions is not established from the record. The subagent's own records carry no permissionMode key; inheritance follows the documented rule that a parent's bypassPermissions "takes precedence and can't be overridden" (sub-agents → Permission modes). This affected a local development checkout, not a production runtime or cloud service. |
| Sandbox (user settings.json) | "enabled": true, "failIfUnavailable": true, "autoAllowBashIfSandboxed": true, "allowUnsandboxedCommands": true. permissions.additionalDirectories includes /Users/<user>/code/github.com, so the code root is inside the sandbox write allowlist. filesystem.denyWrite lists only credential dirs plus /etc, /usr, /System. |
| Permission rules | permissions.ask contains "Bash(rm -rf *)" (and "Bash(sudo *)"). permissions.deny contains only Read(...)/Edit(...) rules. No rm allow rule in any settings file; project allowedTools is []. |
| Hooks | None found. No "hooks" key in any inspectable settings file; ~/.claude/hooks empty; installed plugins define only SessionStart/SessionEnd/Stop hooks; no PreToolUse/PostToolUse anywhere. (The transient claude-settings-<hash>.json referenced by the sandbox policy no longer existed when checked and could not be inspected.) |
| Orchestrating script | Passes no permission, sandbox, or allowedTools options to the subagent; its preamble instructs read-only operation and confines test fixtures to $TMPDIR. |
| Is this a regression? | Unknown; not tested on earlier versions. The Linux analog (#45853, ENOENT on $TMPDIR, bubblewrap) is closed as completed and a 2.1.101 CHANGELOG entry fixes that symptom; no CHANGELOG entry mentions macOS mktemp or _CS_DARWIN_USER_TEMP_DIR. |

What limited the damage

• Protected .git paths. Every .git/config and .git/hooks/* unlink in the preserved output was refused (Operation not permitted), leaving the enclosing directories Directory not empty. These were nested repositories' .git directories (<owner>/<repo>/.git, depth 2); the cwd itself is not a git repository, and the docs list the "hooks and config inside .git" protection under "In your working directory only", so which built-in rule fired is inferred. The user's denyWrite list does not name .git, so it was not user configuration.
• User Read/Edit deny rules merged into the sandbox boundary. .env* files were found intact in the stripped repositories inspected afterwards (the rm output is truncated, so "every" cannot be shown). The docs list no built-in .env protection; they state Read/Edit deny rules are merged into the sandbox boundary, and the user's settings deny Read/Edit on **/.env*. Reproduced: inside the sandbox, .env under the code root can be neither created nor removed (operation not permitted), while the same file under $TMPDIR can.
• Protections that reach deeper than documented. A post-incident probe under the code root found .vscode/settings.json and .gitmodules also undeletable/uncreatable at depth (operation not permitted), though the docs place .vscode and .gitconfig protection under "In your working directory only" (sandboxing → Protected paths) and the user has no deny rule for either. .claude/settings.local.json was not denied at depth in the same probe, so its survival in one repository is unexplained — plausibly the traversal simply never reached it.
• The default 2-minute Bash timeout. No timeout parameter was passed; the harness reported Command timed out after 2m 0s, exit 143, at 120.04 s. The docs say a command reaching its timeout is normally moved to the background rather than stopped, with three exceptions, one being "a compound command Claude Code can't fully parse" (tools-reference → Timeout and output limits); this command (heredoc plus command substitution) appears to fall in that case, which is why it stopped instead of backgrounding. Whether the rm child actually terminated at that point or continued as an orphan is not verifiable from the transcript (cf. #90672, #85200); intact survivors show rm did stop at some point.

What did NOT prevent it

• Critical-path check (the gap this issue asks to close). The docs list "Your working directory and its parents" as a critical path that prompts even in bypassPermissions, and already treat rm -rf "$DIR"/* as critical "because the command becomes a removal from the filesystem root when the variable is empty". Here the variable was empty too, but cd "" && pwd -P turned it into the cwd, and the documented critical-path list names only "a glob or trailing slash directly under a shell variable" (rm -rf "$DIR"/*); a bare rm -rf "$VAR" is not on it (see What's Wrong, point 2). The 2.1.208 change (catastrophic removals inside $(…) now prompt) does not obviously reach a target that is only the cwd at runtime. No critical-path prompt is recorded, and the 120.04 s elapsed time leaves no room for one.
• Bash(rm -rf *) ask rule (present in user settings.json). No prompt is recorded for the incident call, and its 120.04 s elapsed time equals the default timeout exactly, leaving no room for a prompt wait. The docs say content-scoped ask rules "still force a prompt even for sandboxed commands"; that this one did not is the known #76850 symptom (bot-closed as duplicate of #6527, OPEN; #42797 CLOSED as completed 2026-08-16) and is not argued here. Whether the subagent's assumed bypassPermissions inheritance or the multiline form mattered is not established.
• Classifier. Not consulted if the subagent inherited bypassPermissions (assumed, see "Not verified"; in that mode the docs say critical-path removals "Asks you to approve it"); no classifier record exists. Even in auto, the 2.1.205 rule targets a variable "that isn't assigned anywhere in the conversation the classifier sees"; T was assigned in the same command, so it would not have applied.
• set -e (errexit). Ineffective in the Bash tool (step 4); the eval-wrapper mechanism is inferred from behaviour and #90611, not from harness source.
• Hooks. No PreToolUse/PostToolUse hook was found in any inspectable settings source or enabled plugin, so no hook was in a position to intercept the call.
• Sandbox filesystem boundary. The cwd and the code root are inside the write allowlist by design, so deleting their contents (other than protected paths) is permitted.
• Task prompt constraints. The prompt instructed read-only operation and confined fixtures to $TMPDIR, but these are model-level instructions only; as the docs state, "Permission rules are enforced by Claude Code, not by the model."
• Bash tool scratch guidance. The docs' advice to "create scratch directories with mktemp -d instead of relying on $TMPDIR" is given for the filesystem-isolation-off case (motivated by Linux, where $TMPDIR may be unset). This incident ran with isolation on, where the docs promise $TMPDIR is set and writable. The hazard is that on macOS a template-less mktemp -d writes under _CS_DARWIN_USER_TEMP_DIR, not $TMPDIR, and that location was denied here, so on this host a bare mktemp -d was unsafe under isolation-on; the mechanism (template-less -t preferring _CS_DARWIN_USER_TEMP_DIR) suggests it generalises to macOS, untested on other hosts.

Impact

• Target: the user's code root, laid out as <owner>/<repo>. A count made afterwards found roughly 160 top-level directories at that level, mostly local git clones plus some non-repository output folders.
• After the incident, roughly three quarters of those top-level directories were stripped or non-functional and the rest were intact. The survivor set is consistent with rm having stopped before reaching them in directory-iteration order; that it stopped at the timeout is inferred from the survivor pattern, not shown in the truncated tool output.
• Roughly 90 percent of the clones under the worst-affected owner directory were stripped to .git/config + .git/hooks/*.sample (plus any surviving .env*).
• A post-incident survey counting .git directories at every depth found under a third still had an objects/ store.
• .env* files were intact in every stripped directory inspected afterwards (output truncated, so this is not shown for all of them); content that had been pushed to a remote was recoverable by re-cloning; unpushed commits and other local-only material in deleted paths may be unrecoverable.
• Three fixture entries (d700, f400, f600) were created directly in the code root before the delete and are presumed removed by it (their removal is not visible in the truncated output).
• The tool call ran for 120 s before the harness reported the timeout; whether deletion continued after that is unverified (see below).

Suggested mitigations

1. Extend the critical-path rule from rm -rf "$VAR"/* to bare rm -rf "$VAR", in the same rm/rmdir critical-path check that already covers the glob form, at least when VAR is assigned in the same command from a command substitution, routing it through the existing per-mode critical-path flow. Of the changes listed here, this is the one that would have prompted in bypassPermissions; it would also cover a Workflow subagent running in the documented acceptEdits.
2. macOS sandbox + mktemp: allow writes to the Darwin per-user temp dir (getconf DARWIN_USER_TEMP_DIR) inside the sandbox, or change the Bash tool guidance to mktemp -d "$TMPDIR/tmp.XXXXXX", and document that BSD mktemp -d without a template does not honour $TMPDIR.
3. Bash tool guidance for cleanup: a prefix guard before removing a temp variable, e.g. case "$T" in "$TMPDIR"/*) ;; *) echo "refusing to remove $T" >&2; exit 1;; esac before rm -rf "$T", and never rm -rf a variable that was not assigned from a literal or a guarded mktemp result.
4. Record permission evaluation in the transcript. Neither the subagent nor the parent transcript contains any record of whether ask rules, the critical-path check, or the classifier evaluated this call; a per-call record would make incidents like this diagnosable.
5. set -e in the Bash tool — tracked in #90611; noted here because agents write set -euo pipefail believing it protects cleanup code.

Related issues

• #90611 (OPEN) — set -e inert in the Bash tool because the command runs as eval in a non-final && list; explains step 4.
• #75859 (OPEN), #88462 (OPEN) — closest analogs: agent-written cleanup rm -rf on a mis-resolved variable ($HOME), no prompt; #75859 also cut short by the 2-minute timeout; #88462 lists earlier reports of the rm -rf-without-permission class.
• #75861 (OPEN) — read-only Explore subagent executed rm -rf outside its scope with no prompt.
• #76850 (CLOSED; bot-closed as duplicate after a bot flagged #6527/#42797/#63111), #6527 (OPEN), #42797 (CLOSED as completed 2026-08-16), #63111 (CLOSED, not planned) — content-scoped ask rules vs sandbox/auto mode; known, not the subject here. #42797's closing comment asks that recurrences on a current version be reported with the exact rule, command, version and claude doctor output.
• #89064 (OPEN) — reported that workflow subagents inherit the session's permission mode, contrary to the workflows.md text as of 2.1.241; that sentence is no longer in the docs, which now document inheritance (sub-agents → Permission modes). Relevant to what regime this subagent ran under.
• #45853 (CLOSED as completed, Linux/bubblewrap) — mktemp -d failing inside the sandbox because $TMPDIR did not exist (ENOENT); the macOS case here is different (EPERM on the Darwin per-user temp dir while $TMPDIR was writable).
• #91643 (OPEN, macOS ≥2.1.251) — plugin-eval sandbox denies every Bash write because a /private/tmp denyWrite covers the /tmp/e-* sandbox root; it contains one incidental /private/var/folders/<xx>/<hash>/T/xcrun_db EPERM line, never mentions mktemp, and here $TMPDIR was writable, so the mechanism differs. Listed so this is not merged into it.
• #90672, #85200 — Bash timeout / TaskStop do not kill the child process tree; relevant to whether the rm actually stopped at 120 s.

No existing issue found whose title describes this chain (mktemp -d empty → cd "" → pwd -P = cwd → rm -rf "$T" from a Workflow subagent); searches for "mkdtemp failed" and "mktemp" + "Operation not permitted" returned nothing relevant.

Not verified

• Whether the rm process stopped at the 120 s timeout or continued orphaned (cf. #90672, #85200).
• Full blast radius: the tool result is truncated (~10 KB kept, 20,044 characters dropped); the .git survey figures are the subagent's own post-incident counts, and the top-level and per-owner proportions were measured after the fact and are approximate; exact counts can be supplied privately.
• How the parent session came to run in bypassPermissions (every permissionMode record in that session carries it; settings.json says defaultMode: auto) and whether the subagent inherited it (its records carry no permissionMode key; cf. #89064).
• That the sandbox is what denied /var/folders/<xx>/<hash>/T (inferred from the EPERM; the seatbelt profile was not inspected), and the eval-wrapper mechanism behind the errexit failure (behavioural repro plus #90611; harness source not inspected).
• Whether a permission dialog was shown for any post-incident probe is unknown: the transcript records no permission decisions either way, and issue-to-result timings are only suggestive (two probes ~20 minutes each, consistent with a dialog; one ~6 s against ~0.1 s for an adjacent probe, ambiguous; one ~1 s). Not argued here.
• Related issues #6527, #42797, #63111, #76850, #90611, #89064, #75859 and #88462 were re-read directly (gh issue view); the remaining cross-links were read via gh search output and are cited for relevance only.