feat(browsers): install the Microsoft 365 web apps through firefoxpwa

[Bad3r]

Summary

The initial implementation, validation fixes, and review remediations are described below.

1. feat(browsers): Microsoft 365 web apps through firefoxpwa

firefoxpwa keeps its site list in a profile database under $XDG_DATA_HOME/firefoxpwa, so a suite clicked together in
the browser extension survives neither a reinstall nor a move to another host.

• packages/firefoxpwa-site-installer: the shared builder every firefoxpwa site installer is made with. It supplies
  the prelude they all need (data_dir, config_file, FFPWA_USERDATA, XDG_DATA_HOME, the 0700 directory) and takes
  the lock that keeps two of them off config.json at once, which firefoxpwa rewrites whole through File::create
  with no lock of its own. Both existing installers lose their duplicated preludes to it, and an installer that skips
  the lock cannot exist, since that is how they are built.
• packages/firefoxpwa-m365-install: oneshot installer built from the DMail installer's site bookkeeping (the ulid,
  origin and applied-URL records kept next to config.json, plus the pending record covering the kill window inside
  firefoxpwa site install), with a per-entry loop on top. An entry the installer decides it must not act on is
  counted and reported at the end rather than aborting the run, so one refusal does not cost the remaining entries
  their install. A failed write is not a refusal: it aborts under errexit, because the records are what
  authenticate a site on the next run.
• modules/browsers/firefoxpwa/m365.nix: firefoxpwa-m365 user service, layered onto the existing
  browsers.firefoxpwa Home Manager key. No secret to wait for, so it is ordered against nothing: its ExecStart path
  changes with the app table and systemd.user.startServices = "sd-switch" restarts it on the switch that changes it.
  That is the only switch it runs on, so transient installer faults retry themselves (Restart=on-failure,
  RestartSec=1080, bounded by StartLimitIntervalSec=10800 and StartLimitBurst=5) instead of sitting failed
  until the next login. Permanent user-action refusals return EX_CONFIG 78, which the unit treats as successful and
  non-restarting. Their starts still count toward that five-start window, which leaves room for corrective switches
  while pacing fast retries across the same window. Ordered
  After the DMail unit, since firefoxpwa rewrites the whole of config.json with no lock and the two would
  otherwise start together at login. The lock is what actually keeps them apart; the ordering keeps the common case
  from reaching it.
• modules/browsers/firefoxpwa/apps.nix: programs.firefoxpwa.m365.{enable,apps} at NixOS scope, next to the existing
  dmail.enable, with assertions against duplicate keys and names.
• modules/browsers/firefoxpwa/_m365-apps.nix: the default catalog (Microsoft 365, Word, Excel, PowerPoint, Outlook,
  OneNote, OneDrive).

Start URLs are the bare cloud.microsoft origins: the manifest scope is fixed at install time and
firefoxpwa site update cannot rewrite it, so scope has to be the origin, and the landing paths Microsoft redirects to
(/en-us/, /mail/, /tasks/) are locale or tenant dependent. Checked on 2026-08-04 and left out on purpose:
teams.cloud.microsoft answers Gecko with /v2/unsupported-browser, visio.cloud.microsoft redirects to
m365.cloud.microsoft and would leave its own scope on first load, and clipchamp.cloud.microsoft does not resolve.

programs.firefoxpwa.m365.enable defaults to false and no host sets it yet.

2. fix(checks): stop trusting compgen in build-time shell text

The leftover-temporary assertion first written for the m365 check reported a pass on every run while checking nothing:
the bash a runCommand builder runs is built without programmable completion, so compgen -G resolved to no command,
and a condition context turns that into a false rather than an error. Probed both interpreters to confirm the split:
type -t compgen in a plain runCommand reports MISSING, a bash from nativeBuildInputs reports HAVE.

• tests/prune-old-stashes/run.sh used the same builtin for its defined-but-never-ran guard, the one thing stopping a
  test function from being added and silently never called. It passes today only because
  modules/meta/script-tests.nix puts pkgs.bash (resolved to bash-interactive) on PATH. Now declare -F.
• m365-check.nix proves the detector before trusting it: a planted .next file has to be reported first.
• checks.build-time-shell scans modules/, packages/ and tests/ for the builtin at a command position, plain or
  negated, and plants both spellings the scan must hit before scanning the tree, so the guard cannot go quiet the way
  the assertion did. scripts/ is out of scope: it runs under the user's own bash.

3. feat(meta): run statix across the whole tree as a flake check

statix reached only staged files. modules/meta/pre-commit.nix invokes hook-statix with filenames and nothing in
.github/workflows/check.yml runs statix at all, so a lint in a file nobody edits again was reachable on main
indefinitely. The repeated options assignment fixed in apps.nix on this branch was caught only because that file
happened to be staged. checks.statix-tree runs hook-statix with no arguments (its own whole-tree branch), so CI and
pre-commit share one binary and one set of lints. passthru.runtimeCheck opts it into the workflow's runtime build
step, which discovers checks by that marker, so no workflow edit is needed. Source narrowed to .nix files through
lib.fileset, minus docs/nixos-manual/, the upstream mirror both the hook and treefmt already exclude. A lint is
planted and has to be reported before the tree is scanned, since nothing else calls hook-statix without arguments.
The tree is clean under it today.

4. Review round

• fix(browsers): install_app ran as the left side of || failed=$((failed + 1)), and bash ignores -e for the
  whole body of a function invoked that way, including every compound command inside it. A record that failed on a
  full or read-only filesystem was silent, the pending record was then removed, the entry was reported installed, and
  every later run refused it as foreign with no recovery short of firefoxpwa site uninstall. The per-entry status is
  now collected by a refuse helper, so install_app is called as a plain command and errexit covers the record
  writes, the pending write, the manifest jq and the base64.

• fix(browsers): the installer returns non-zero for a site that registered and then failed, expecting the next run to
  repair it, but nothing produced that run: sd-switch restarts a unit only when its own text changed, and
  RemainAfterExit keeps the failed unit there until the next login. dmail.nix gets its rerun from
  PartOf = sops-nix.service; this unit now gets it from a bounded Restart=on-failure for retryable faults.
  Permanent refusals use EX_CONFIG 78, and the five-start window accounts for the refusal and corrective switches
  while the retry delay paces fast faults across that window. The
  programs.firefoxpwa.m365.enable text that claimed failure "on every switch and login" is corrected with it.

• feat(browsers): apps.*.url was a bare str, so m365.cloud.microsoft or htps://... built fine and surfaced
  only as a runtime refusal in a user unit's journal. Now strMatching "https?://[^[:space:]]+".
  Round two, on the commits above:

• fix(checks): the command-position alternation required compgen to follow the keyword or operator immediately, so
  if ! compgen -G ... matched none of its branches and passed the tree scan. Each alternative now admits an optional
  !, and the self-test plants both spellings and requires two hits, since a fixture for one of them proves only the
  branch it happens to take.

• test(browsers): nothing applied the key option's strMatching to the shipped catalog, because an option's type
  is checked when its value is forced and no host forces this one. Asserted next to the duplicate-key and https
  assertions already there for that reason.

• test(browsers): the stub could fail site install two ways but never site update, leaving untested that a failed
  update does not advance applied_file and so is retried rather than swallowed by the no-op fast path.

Round three:

• fix(checks): the scan helper ended in || true, which collapsed grep's three-valued status. 1 is "matched
  nothing", but 2 and up mean grep could not read a path it was given, and both produced an empty result and a
  reported pass, the same fail-open shape the check exists to catch. The status is now returned when it exceeds 1, so
  both callers abort.

Round four:

• fix(meta): checks.statix-tree scanned docs/nixos-manual/, the vendored upstream mirror that both the pre-commit
  hook and treefmt exclude, so the check was strictly wider than the hook it shares a binary with and the next
  update-nixos-manual.sh sync could fail CI on code this repo cannot fix.
• test(meta): nothing else calls hook-statix without arguments, so a clean $out was indistinguishable from a run
  that walked nothing. An empty let-in is planted and has to be reported first.

Round five:

• fix(browsers): nothing ordered firefoxpwa-m365.service against firefoxpwa-dmail.service. Both are
  WantedBy = [ "default.target" ] and both drive firefoxpwa site install, which rewrites config.json unlocked, so
  on a host with both toggles on they race at login and the later writer drops the other's site. tpnix already sets
  dmail.enable, so this was one m365.enable away from being live.
• fix(browsers): editing an entry's name while keeping its key landed in the fresh-install branch, registering a
  second site and overwriting the only record of the first, leaving the original app and its launcher orphaned in
  silence. Refused now, told apart from the documented uninstall by the recorded ulid still being present in
  config.json. The stub's ulid allocation was derived from the site count, so it reused the id of a deleted site;
  a counter now, since a real ulid is unique for the life of the profile.

Round six:

• fix(browsers): the ordering added in round five does not close the race. After= is enforced across transactions,
  not only within one, but Home Manager activates reloadSystemd before the sops-nix step, so a switch starts the m365
  unit and only then restarts the dmail unit through PartOf, the direction an After= on the m365 unit does not
  constrain. The lock in the shared builder is the fix, and it is in the builder rather than in the two installers
  because more site installers are coming and a lock only some of them take is not a lock.
• test(browsers): deepSeq forced the After= value but asserted nothing about it, and systemd ignores an ordering
  dependency naming a unit that does not exist, so a typo would have been silent at switch and at login.

Round seven:

• fix(browsers): the lock acquire blocked unbounded and silent, so a queued installer could wait past the user
  manager's default TimeoutStartSec of 90s and be killed with nothing in the journal naming the lock. It now
  announces the wait before blocking, and both units raise TimeoutStartSec to 900, since being killed for waiting is
  not a fault and the default is shorter than a legitimate wait.
• test(browsers): site-lock-check.nix proves the builder serializes and deliberately names no installer, which left
  nothing proving today's two go through it. Each installer's own check now greps its built text for the shared lock
  path, so a rewrite back to a direct writeShellApplication fails.

Round eight:

• docs(browsers): key reads as a naming detail but every record path is m365-<key>-*, so editing it while keeping
  name moves the records to a slug that has none and the entry hits the refusal that tells the user to run
  firefoxpwa site uninstall, destroying a working PWA profile. Documented, and pinned by a check.
• fix(checks): the site-lock control's result was a race outcome decided by a fixed pause, so a busy builder could
  fail it on a change that touched nothing. The two runs now rendezvous, which makes the outcome depend on whether the
  peer can enter rather than on which process starts first.

Round nine:

• fix(browsers): the duplicate-name assertion only saw the m365 list, but the launcher name is the idempotency key in
  a config.json every site installer shares, so an m365 entry named DMail collided with the DMail site and hit a
  refusal whose only remedy destroys that site's PWA profile. programs.firefoxpwa.siteNames is now an internal
  registry each enabled site contributes to, with one assertion over the union, so a site added later joins by
  contributing rather than by someone widening a comparison. New checks.browsers/firefoxpwa-apps-eval forces the
  option module, which no host does.
• docs(browsers): the m365 module header still said the unit "is ordered against nothing" after the After= went in
  below it.

Round ten:

• fix(browsers): promoting the DMail launcher name to an option in round nine made an edit reachable that the DMail
  installer had no guard for, and it is worse than the m365 case it mirrors: those records are keyed by the entry's
  slug, so a name edit lands on a missing-record refusal, while these paths are fixed and the installer silently
  registers a second site and overwrites the only records of the first. Same guard ported over, plus the option text
  and a check case.

Round eleven, both on assertions that could not fail:

• test(browsers): the m365 stub read manifest.scope from --document-url rather than from the data: manifest the
  installer built, and every entry declared a start URL equal to its own origin, which normalizes identically either
  way. Building the manifest with scope: $url kept the check green while the real firefoxpwa would install a scope
  that excludes nothing. The stub decodes the manifest now, and a new entry installs below its own origin, which is
  what discriminates.
• test(browsers): the dmail rename assertions were invariant under a stub that writes every install to one hardcoded
  ulid, so removing the guard overwrote the site rather than adding one and only the exit status went red. The site's
  own name is now the observable.

Rounds twelve to fifteen, in the same vein:

• fix(browsers): the rename guards read jq -e failure as "the recorded site is gone", so an unreadable
  config.json fell into the fresh-install branch and duplicated the site. Both scripts separate those two statuses
  everywhere else they read that file.

• test(browsers): the dmail reinstall cases matched "installed", which is also a substring of "already installed
  with current URL", so they pinned neither the branch nor the name.

• test(browsers): both m365 rerun cases passed an empty message fragment, so deleting the installer's no-op fast path
  left every assertion green. Silence is the observable now.

• feat(browsers): the url type admitted userinfo, so a start URL embedding credentials built fine and surfaced only
  as the installer's runtime refusal. These are static strings, unlike the DMail secret, so it is rejected at eval.

• Rejected, with the reasoning recorded in both check files: the reviewed claim that
  case "$out" in *"$want_text"*) [ "$rc" = "$want_rc" ] && ok=0 ;; esac aborts the builder under errexit when the
  fragment matches but the status does not. It does not, for the same reason the installer defect above existed: bash
  ignores -e for the left side of an && list and the enclosing compound inherits that state.

Round twenty:

• fix(meta): the build-time shell detector matched command substitution but missed process substitution,
  allowing compgen immediately after a process-substitution opening to pass the tree scan. The shared
  command-opening branch now covers both process-substitution directions, and the planted self-test requires
  all eight command-position fixtures.

Round twenty-one:

• fix(meta): the detector also missed legacy backtick command substitution, so an assignment capture could
  pass the tree scan. An assignment-capture anchor and a ninth planted fixture now cover this form without
  matching the scanned prose that documents compgen.

Round twenty-two:

• fix(meta): the assignment-anchored backtick branch missed the quoted conditional assertion shape. The
  backtick branch now covers the realistic shell openings for this form, and a tenth planted fixture proves
  the widened alternative.

Test plan

• nix fmt
• nix flake check path:. --accept-flake-config --no-build --offline (exit 0)
• nix build path:.#checks.x86_64-linux."browsers/firefoxpwa-m365": drives the real installer against a stub firefoxpwa
  through a fresh install, an idempotent rerun, a same-origin move applied with site update, a cross-origin move
  refused, a start URL carrying credentials refused before any site lookup, a same-named site the unit did not install
  refused rather than adopted, an entry that never registers not stopping the others, an install that registers and then
  fails repaired on the next run rather than duplicated, a record write that fails stopping the run with the pending
  record intact and recovering on the next run, an entry renamed onto its own live site refused while the same stale
  record after an uninstall still reinstalls, the shipped catalog installed end to end, the leftover-temporary
  detector planted before it is trusted, and a failed site update counted as a refusal without advancing the
  applied-URL record, and an entry installed below its own origin still scoped to the origin. 64 assertions. Restoring the || failed=$((failed + 1)) call site turns the
  three new ones red.
• nix build path:.#checks.x86_64-linux."browsers/firefoxpwa-dmail"
• nix build path:.#checks.x86_64-linux."browsers/firefoxpwa-site-lock": two installers from the shared builder
  serialize on a read-rendezvous-write counter (ends at 2); the same pair built with writeShellApplication directly
  loses an update (ends at 1), which is what shows the assertion can fail. Confirmed against a deliberate 3-second
  startup skew
• nix eval path:.#checks.x86_64-linux."browsers/firefoxpwa-apps-eval".drvPath: the launcher-name collision, the
  shipped catalog alongside DMail passing, a name claimed only while its site is enabled, and duplicate keys. Dropping
  the DMail registration turns the first red
• nix eval path:.#checks.x86_64-linux."browsers/firefoxpwa-module-eval".drvPath: extended with the m365 unit, the
  empty-app-list warning and the disabled cases, since the module's mkIf blocks are unforced while no host enables the
  toggle. Forces the whole m365 unit, so the restart policy is evaluated too.
• systemd-analyze verify --user on the rendered firefoxpwa-m365.service, ordering included: exit 0, and exit 1 with
  Restart=always in its place, which is what makes the acceptance meaningful.
• nix build path:.#checks.x86_64-linux.build-time-shell: passes on the clean tree, and its ten planted
  command-position fixtures include process substitution, backtick assignment capture, and a quoted
  conditional backtick form. It fails with the expected message when a tests/_scratch/probe.sh using the
  builtin is planted. Fails with exit code 2 and the path named when an unmaterialized directory is added to
  the scan arguments.
• nix build path:.#checks.x86_64-linux.statix-tree: the materialized source has no docs/nixos-manual, and the
  check fails both with a let in { } planted under modules/ and with the zero-argument branch stubbed to exit 0
• nix build path:.#checks.x86_64-linux.script-tests-prune-old-stashes (47 passed)
• nix develop path:. --fallback -c pre-commit run --files <changed files> (deadnix, nix-parse, shellcheck, statix,
  treefmt, typos)

[claude]

Claude finished @Bad3r's task in 12m 3s —— View job

---

Review complete

• Read PR diff
• Inspect changed files against repo conventions
• Analyze for issues/enhancements
• Post findings

Two findings, both [ENHANCEMENT], both on modules/meta/build-time-shell.nix; posted inline.

File	Line	Finding
modules/meta/build-time-shell.nix	31	Scan excludes scripts/, but modules/meta/script-tests.nix copies five scripts into a runCommand and executes them there, so the stated rationale does not hold for them.
modules/meta/build-time-shell.nix	59	Operator alternatives require whitespace, so true;compgen, true|compgen, true&&compgen and (compgen …) pass the scan; all ten planted fixtures use the spaced form, so the self-test cannot expose it.

Nothing else surfaced. I traced the installer state machine in packages/firefoxpwa-m365-install/default.nix (refusal-vs-fault split, exit 78 vs 1, adopt/rename/cross-origin/key-edit branches, errexit reachability of every record write), the shared lock and its two consumers, the systemd policy in modules/browsers/firefoxpwa/m365.nix against module-check.nix's StartLimitIntervalSec >= StartLimitBurst * (TimeoutStartSec + RestartMaxDelaySec) assertion (6000 = 5 × 1200; worst-case fifth start lands at ≈4038 s, inside the window), the url/key option types against apps-check.nix, and the assertion coverage in m365-check.nix, dmail-check.nix and site-lock-check.nix. No correctness defect found in those.

The start-limit-hit lockout after five starts in 100 minutes is a real foot-gun, but it is a deliberate trade-off against the 900 s timeout path and is documented on programs.firefoxpwa.m365.enable together with the systemctl --user reset-failed remedy, so I did not raise it.
• branch feat/firefoxpwa-m365

[github-actions]

No blocking issues found.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e05b9197a6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[Bad3r]

Review round 1 addressed

Nine inline threads, five distinct findings (the two reviewers overlapped on four). All resolved; four commits pushed.

Implemented

Commit	Finding
2413c9bb	install_app ran as the left side of || failed=$((failed + 1)), so bash ignored -e for its whole body. A record that failed on a full or read-only filesystem was silent, rm -f "$pending_file" then destroyed the evidence, and every later run refused the entry as foreign with no recovery short of firefoxpwa site uninstall. Fixed by taking Codex's second option: the per-entry status is collected by a refuse helper, install_app is called as a plain command, and errexit now covers the record writes, the pending write, the manifest jq and the base64 rather than record alone.
42c31d31	The installer returns non-zero for a site that registered and then failed, on the stated expectation that the next run repairs it, but nothing produced that run: sd-switch restarts a unit only when its own text changed, and RemainAfterExit kept the failed unit there until the next login. Now Restart=on-failure, RestartSec=120, bounded by StartLimitIntervalSec=600 and StartLimitBurst=3.
42c31d31	The programs.firefoxpwa.m365.enable text claimed the service "reports failure on every switch and login", which was never true. It now names the switch that moves the entry, the bounded restarts, and every later login.
f3e523a0	apps.*.url was a bare str, so m365.cloud.microsoft or htps://... built fine and surfaced only as a runtime refusal in a user unit's journal. Now strMatching "https?://[^[:space:]]+".

Rejected

The claim that case "$out" in *"$want_text"*) [ "$rc" = "$want_rc" ] && ok=0 ;; esac aborts the builder under errexit when the message fragment matches but the status does not, in m365-check.nix and dmail-check.nix. It does not: bash ignores -e for the left side of an && list, and the enclosing compound inherits that state, so the case returning 1 is not a trigger. Verified in a runCommand builder on bash 5.3.15 with this exact helper and rc=7 against want_rc=0: the FAIL branch printed, the captured output printed, and the following statements ran.

It is the same bash rule as the real defect above, in the opposite direction, so db057b47 records it above the helper in both check files instead of leaving the code to attract a third report.

Beyond the literal comments

• m365-check.nix gained six assertions for the write-failure path: a directory planted where the ulid record's temporary goes makes the redirection fail the way a full filesystem does. They assert the run stops, the following entry was never attempted, the pending record survives, and the next run adopts and repairs. Restoring the || call site turns three of them red, which is what makes them a regression check rather than a description.
• module-check.nix forces the whole firefoxpwa-m365 unit rather than ExecStart and Environment, so the restart policy is evaluated while no host enables the toggle.
• packages/firefoxpwa-dmail-install was checked for the same defect class and does not have it: no install_app-style function, every write at top level, exit rather than return throughout. No parity change needed.
• The PR body's m365.nix bullet, which described the sd-switch trigger as the only rerun, and its test plan.

Reliability

The distinction the fix rests on is refusal versus fault. A refusal is a state the installer decides it must not act on (a foreign site under a managed name, a move across origins, an install that never registered); it is counted, the other entries still install, and the entry stays describable. A fault is a failed write to a record or to config.json; it aborts, because those records are what authenticate a site on the next run and continuing past a half-written one is exactly how an entry became permanently refused. The rerun policy closes the other half: the code path that returns non-zero expecting repair now has something that reruns it, bounded so a permanent refusal stops instead of looping.

Restart=on-failure for Type=oneshot was verified, not assumed: systemd 261.1's man page disallows only always and on-success, and systemd-analyze verify --user accepts the rendered unit while rejecting the same unit with Restart=always.

Validation

• nix build path:.#checks.x86_64-linux."browsers/firefoxpwa-m365" (51 assertions), plus the planted-regression run
• nix build path:.#checks.x86_64-linux."browsers/firefoxpwa-dmail"
• nix eval path:.#checks.x86_64-linux."browsers/firefoxpwa-module-eval".drvPath
• nix build path:.#checks.x86_64-linux.{statix-tree,build-time-shell}
• nix flake check path:. --accept-flake-config --no-build --offline (exit 0)
• systemd-analyze verify --user on the rendered unit, both accepted and deliberately-broken forms
• nix develop path:. --fallback -c pre-commit run --files <changed files>

[Bad3r]

Review triage for this iteration is complete. Accepted and implemented: clarified the systemd retry-budget comment and reset-failed recovery; expanded the compgen detector to case-arm, group, and subshell positions with seven planted regression fixtures; and improved both installer test helpers to report the expected output fragment on status failures. No valid feedback was rejected in this iteration. Production reliability is improved by aligning operational documentation with actual systemd behavior, keeping the detector self-tested across each supported command position, and making assertion failures actionable. Targeted build-time-shell, Firefox PWA M365, and DMail checks plus formatter and pre-commit hooks pass.

[claude]

[ENHANCEMENT] The header justifies excluding scripts/ with "scripts/ runs under the user's own bash, where the builtin exists". That is not true for the five scripts modules/meta/script-tests.nix copies into a runCommand and executes: scripts/prune-old-stashes.sh, scripts/prune-stale-worktrees.sh, scripts/git-worktree-remove-safe.sh, scripts/run-packages-updaters.sh and .github/scripts/upstream-tracker.sh (lines 13–75 there, run at line 144 via bash tests/${name}/run.sh after patchShebangs).

Those run under whatever pkgs.bash the suite happens to put on PATH — the exact dependency e87a1f6 removed from tests/prune-old-stashes/run.sh in this PR. tests/**/*.sh is scanned for that reason; the scripts those same builders execute are not, so a compgen -G guard added to scripts/prune-stale-worktrees.sh gets no coverage from this check while its failure mode is identical.

The replacements (declare -F, declare -p, a nullglob array) are plain builtins everywhere, so widening costs the user-facing invocation nothing. The header comment needs the matching correction.

Suggested change

	(lib.fileset.fileFilter (file: file.hasExt "sh") ../../tests)
	(lib.fileset.fileFilter (file: file.hasExt "sh") ../../tests)
	(lib.fileset.fileFilter (file: file.hasExt "sh") ../../scripts)

Fix this →

[claude]

[ENHANCEMENT] The operator alternatives require [[:space:]]+ after the token, so the unspaced spellings pass the scan: true;compgen -G "$out"/*.next, true|compgen -A function, true&&compgen -A function and (compgen -A function) are all valid bash and all matched by none of the four branches. ;, |, &&, {, (, ) do not need a following blank in bash; only the reserved words do.

The self-test cannot expose this, because every one of the ten planted fixtures (lines 80–89) writes the spaced form — 'true | %s -A function\n', '( %s -A function )\n', 'case x in *) %s -A function ;; esac\n' — so each proves only the branch it already takes. Splitting the operators out with [[:space:]]* while keeping [[:space:]]+ for the keywords closes it without loosening the keyword anchor:

Suggested change

	'^[[:space:]]*!?[[:space:]]*compgen\b|[$<>]\(!?[[:space:]]*compgen\b|["=(|;&]`!?[[:space:]]*compgen\b|(if|elif|while|until|then|else|do|;|&&|\|\|?|\{|\(|\))[[:space:]]+!?[[:space:]]*compgen\b' \
	'^[[:space:]]*!?[[:space:]]*compgen\b|[$<>]\(!?[[:space:]]*compgen\b|["=(|;&]`!?[[:space:]]*compgen\b|[;&|(){}][[:space:]]*!?[[:space:]]*compgen\b|(if|elif|while|until|then|else|do)[[:space:]]+!?[[:space:]]*compgen\b' \

Verified against the tree as it stands: every existing compgen occurrence (this file's own message at line 99 and comment at line 8, m365-check.nix:640, tests/prune-old-stashes/run.sh:1584) is preceded by :, a space or a backtick, none of which is in the new class, so the widened branch adds no false positive. Plant the unspaced forms alongside the spaced ones and raise the expected count so the new branch is proven too.

Fix this →