fix(#125): stop walking ancestors in ensure_folder_exists (flickering cmd.exe windows)

[YedPool]

Summary

Fixes MLFlexer#125 — flickering cmd.exe (or wslhost.exe for WSL-default-domain users) pop-up windows on every WezTerm launch and every Ctrl+Shift+R config reload.

Root cause

ensure_folder_exists walked every ancestor of the target path and probe-wrote each one to test existence. dir_is_accessible is a probe-write — it returns false for directories that exist but aren't writable to the current user, e.g. C:\Users on a non-admin Windows account. For each such ancestor, shell_mkdir then ran os.execute('cmd /c mkdir ...'), which on Windows spawns a visible cmd.exe console window — the flicker.

change_state_save_dir calls ensure_folder_exists 4× per init (workspace/window/tab/instances) and setup_claude_session_hooks adds a 5th. init() runs on every launch and every config reload, so affected users saw 4–N flashes per event.

The earlier MLFlexer#125 fix attempt (replacing os.rename with probe-write) addressed one false-negative but left the read-only-ancestor false-negative in place, which is why @pszlendak (2026-03-19) and @pine2D (2026-05-10) reported the bug still reproduces on this fork.

Fix

cmd /c mkdir <path> and mkdir -p <path> already create intermediate directories automatically. The walk was pure overhead — and the source of the bug. This PR removes it:

• Drop parse_root and mkdir_if_missing (dead after the walk goes).
• Keep a small drive-relative normaliser (C:foo → C:\foo) so the documented behaviour is preserved (and the existing spec test still passes).
• Probe-write only the leaf target — leaf dirs always live in user-writable areas (AppData, ~/.claude), so the false-negative cannot occur.

plugin/resurrect/utils.lua | 111 +++++++++++----------------------------------
1 file changed, 26 insertions(+), 85 deletions(-)

Why not wezterm.run_child_process?

I tried it. During plugin init() it errors with "attempt to yield across a C-call boundary" — same for wezterm.read_dir and wezterm.glob. All three are async APIs that can't run from init context. os.execute is the only viable option for the rare miss case (genuinely-missing leaf dir on first install), and the new code only invokes it then.

Test plan

Verified on wezterm 20240203-110809-5046fc22 / Windows 11 by instrumenting shell_mkdir to log every invocation, then running wezterm show-keys repeatedly (same config-load path as a real launch / config reload):

Run	Pre-existing leaves	shell_mkdir calls
Launch 1	none (fresh install)	2 — state/instances, .claude/pane-sessions (legitimate)
Launch 2	both exist	0
Launch 3	both exist	0

Existing spec coverage still applies (nested mkdir, idempotent re-entry, spaces in path, file-as-obstacle, relative paths, drive-letter abs, drive-relative normalisation).

Notes

• Closes the long-standing user-visible bug. After this PR, steady state is zero flashes.
• Related: PR fix: narrow init keywords to { "YedPool" } so both URL spellings load #13 (separate bug — dev.wezterm keyword mismatch silently aborts plugin load on fresh install). fix: narrow init keywords to { "YedPool" } so both URL spellings load #13 must merge for this fix to take effect for new users.

🤖 Generated with Claude Code