Regression in 1.0.26: window move/resize shortcuts and snippet tags stopped working

[allgemeiner-intellekt]

After updating SuperCmd from 1.0.25 to 1.0.26, I ran into two regressions on macOS.

The first one is with window management. I have shortcuts configured for moving the active window left/right/up/down, and for increasing/decreasing the window size by 10%. After the update, these shortcuts no longer do anything. I also tried running the corresponding commands directly from the launcher, but those did not seem to have any effect either. I have not tested every other window management command, so this report is specifically about the directional move commands and the +/- 10% resize commands.

The second issue is with snippets. Directly selecting a snippet from SuperCmd still works and inserts the snippet correctly. However, snippet tags no longer trigger while typing. In previous versions, typing a configured snippet tag would immediately expand the snippet. In 1.0.26, typing the tag does nothing.

I tried re-granting the relevant macOS permissions and restarting SuperCmd, but the behavior did not change.

I then rolled SuperCmd back from 1.0.26 to 1.0.25 on the same machine, with the same settings, and both features started working again. So this looks like a regression introduced somewhere between 1.0.25 and 1.0.26.

Environment:

• SuperCmd version with the issue: 1.0.26
• SuperCmd version that works after rollback: 1.0.25
• macOS: 15.6.1 (24G90)
• Architecture: Apple Silicon / arm64

[shobhit99]

Thanks for reporting, i did try these on tahoe, it was working. i will try to reproduce it on 15.6.1

[wombatinua]

I second this, stopped working on 1.0.26 (macOS 27 DB 2)

[shobhit99]

@claude can you investigate this

[claude]

Claude finished @shobhit99's task in 39m 41s —— View job

---

Investigation Report: v1.0.26 Regressions

I traced both regressions through the full call stack. Here are the findings:

---

Regression 1: Window Management Fine-Tune Commands (move/resize ±10%)

Why layout commands still work but fine-tune commands don't:

The two command families go through subtly different code paths in src/main/main.ts:

// Layout commands (left/right/top/bottom/center/fill/etc.) — always native first
const success = await executeWindowManagementLayoutCommand(commandId, {
  preferNative: true,   // ← unconditional
  nativeTargetHint,
});

// Fine-tune commands (move-left-10, resize ±10%, etc.) — conditional
const success = await executeWindowManagementFineTuneCommand(commandId, {
  preferNative: !isVisible || hasNativeTargetHint,  // ← conditional
  nativeTargetHint,
});

hasNativeTargetHint is only true if preferredFrontmostApp (from lastFrontmostApp / launcherEntryFrontmostApp) has a non-empty bundleId or path. When the launcher is visible (isVisible = true) and hasNativeTargetHint = false, preferNative evaluates to false — the native window-adjust binary is skipped entirely for fine-tune commands, even though the binary fully supports them (the move-left-10, move-right-10, etc. cases are all present in the AdjustAction enum in src/native/window-adjust.swift).

What happens in the fallback chain when native is skipped:

1. Worker path (executeWindowManagementFineTuneCommand, line 4253): calls captureWindowManagementTargetWindow() which returns early without updating windowManagementTargetWindowId when the launcher window is active. Falls to getNodeSnapshot() → matchNodeWindowForFrontmost(). If lastFrontmostApp is null (e.g., captureFrontmostAppContext() via lsappinfo returned nothing), no target is found → worker path returns false.

2. Renderer fallback (openLauncherAndRunSystemCommand → executeWindowManagementPresetCommandById): calls resolveWindowManagementExecutionContext(), which tries getWindowManagementContext(), getWindowManagementTargetWindow(), and getActiveWindow() — all return null when the launcher has focus. Last resort: getWindowsOnActiveDesktop() → findBestTargetWindowForArea(). This should find a target, but fine-tune presets have requiresShiftEnter = true, which means if findBestTargetWindowForArea returns null (e.g., no windows overlap the current screen area, or node-window-manager returns an empty list), the command returns { success: false, error: 'No target window found.' } — silently, with no user feedback.

Also relevant even when native IS tried: window-adjust checks AXIsProcessTrusted() first. If Accessibility permission was revoked after the 1.0.25→1.0.26 update (a known macOS TCC behavior on app updates), the binary returns {"ok":false,"error":"accessibility_not_trusted"} for both layout and fine-tune — but layout commands handle this silently and fall through to the same renderer path. The difference is that layout presets don't have requiresShiftEnter = true, so they can still succeed with any window on the desktop. Fine-tune presets require a specific target and fail if none is conclusively identified.

Root cause summary: Two compounding problems:

1. The preferNative: !isVisible || hasNativeTargetHint condition skips the native binary for fine-tune when lastFrontmostApp is unset, unlike layout commands which always try native.
2. The requiresShiftEnter = true constraint on fine-tune presets causes silent failure when the full fallback chain can't identify a definitive target window.

Suggested fix: Change fine-tune commands to use preferNative: true unconditionally, matching layout commands. The window-adjust binary looks up the target application via NSRunningApplication.runningApplications(withBundleIdentifier:) — it does not rely on system-wide AX focus, so it can find the previous frontmost app's window even when SuperCmd has focus. The conditional logic adds complexity without benefit.

---

Regression 2: Snippet Keyword Expansion Stopped Triggering

Architecture overview: src/main/main.ts spawns src/native/snippet-expander as a child process, passing all snippet keywords as a JSON array. The binary installs a CGEvent.tapCreate(.cgSessionEventTap, .defaultTap) to intercept keystrokes, buffers typed characters, and emits JSON on stdout when a keyword matches.

What's broken: snippet-expander exits with code 1 if the event tap fails. The failure check is:

// snippet-expander.swift, lines 98–148
let accessibilityOpts: CFDictionary = [kAXTrustedCheckOptionPrompt.takeRetainedValue() as String: true] as CFDictionary
_ = AXIsProcessTrustedWithOptions(accessibilityOpts)   // shows the dialog — returns immediately

// then immediately, without waiting for the user to click Allow:
guard let eventTap = CGEvent.tapCreate(
  tap: .cgSessionEventTap,
  options: .defaultTap,   // ← requires Accessibility permission
  ...
) else {
  fputs("Failed to create keyboard event tap. Check Input Monitoring permissions.\n", stderr)
  exit(1)   // exits before user can respond to the dialog
}

The critical issue: AXIsProcessTrustedWithOptions(prompt: true) shows the Accessibility dialog but returns immediately (it does not block until the user responds). The code then immediately calls CGEvent.tapCreate, which fails because trust hasn't been granted yet, and exits. refreshSnippetExpander() re-spawns it after 500ms, producing an infinite restart loop that never stabilizes.

Permission confusion — misleading error message: The exit message says "Check Input Monitoring permissions", but .cgSessionEventTap with .defaultTap requires Accessibility permission, not Input Monitoring. The separate input-monitoring-request.swift binary handles Input Monitoring (for a different HID tap). Users following the error message grant the wrong permission in System Settings and remain confused about why it still doesn't work.

After macOS app update: macOS TCC often revokes permission grants when an app's code signature changes (common on version bumps). After the 1.0.25→1.0.26 update, both Accessibility permission for snippet-expander and potentially the trust chain to SuperCmd.app may need to be re-granted. But because of the race above, the re-grant never "sticks" — the process exits before the user can confirm.

Suggested fixes:

1. Fix the permission race: Check trust first; if not trusted, show the prompt, then exit cleanly (code 0, not 1) so the user can grant in System Settings. On the next spawn (after the user grants), AXIsProcessTrustedWithOptions will return true immediately and tapCreate will succeed. Exiting with code 0 on the first "not trusted" run prevents the infinite-restart loop from hammering the system and confusing the user.
2. Fix the misleading error message: Change "Check Input Monitoring permissions" → "Check Accessibility permissions" (System Settings → Privacy & Security → Accessibility).
3. Consider consolidating to one permission: Both snippet-expander (Accessibility, .cgSessionEventTap) and input-monitoring-request (Input Monitoring, .cghidEventTap) serve overlapping purposes. Using .cghidEventTap with .listenOnly for snippet expansion would unify both features under a single permission type (Input Monitoring), reducing user confusion.

---

Files to change

File	Change needed
src/main/main.ts ~line 11121	Change `preferNative: !isVisible
src/native/snippet-expander.swift ~line 98–148	Check AXIsProcessTrusted() before attempting tap; exit cleanly (code 0) if not trusted, allowing user to grant permission before next spawn
src/native/snippet-expander.swift ~line 146	Fix error message: "Input Monitoring" → "Accessibility"

[wombatinua]

I want to clarify: after restoring from 1.0.26 to 1.0.25 on macOS 27 window resize features still not working.