[Bug] Local shell commands on Windows can time out immediately due to timeout unit mismatch

Hi, thanks for Alma.

I ran into a Windows-specific local shell issue that looks reproducible and likely not machine-permission related.

Environment

• Alma: 0.0.737

• OS: Windows 10 Home China, build 26200, 64-bit

• Device: HUAWEI MDG-XX

• CPU: 13th Gen Intel Core i5-13420H

• Git installed: C:\Program Files\Git\bin\bash.exe exists

Observed behavior

• Very simple local shell commands in Alma, such as: echo hello can be reported as timed out.

• Running as administrator did not fix it.

• The same command works normally outside Alma.

Why I think this is not just a permissions issue

• On this machine, Alma prefers Git Bash on Windows when Git is installed.

• The command itself is valid and executable.

• After a local patch to Alma’s packaged app, the problem immediately disappeared and local commands started working again.

Most likely root cause It looks like the shell timeout value is passed directly into JavaScript setTimeout() without converting seconds to milliseconds.

In other words, if the tool payload uses:

• timeout: 10

Alma appears to treat that as:

• 10 ms

instead of:

• 10 seconds

This is especially visible on Windows because Git Bash startup is not instant, particularly when launched in login-shell mode.

Evidence from local inspection In the packaged app, the shell execution path appears to use logic equivalent to:

• setTimeout(..., timeout)

After changing it locally to:

• setTimeout(..., timeout * 1000)

the issue was resolved.

I also patched the analogous background/promoted shell timeout path the same way, and both local command execution paths started behaving normally.

Suggested fix

• Convert shell timeout values from seconds to milliseconds before passing them to setTimeout

• Check both foreground and background/promoted shell execution paths

• Consider adding a small regression test on Windows with: echo hello timeout: 10

Optional improvement On Windows, it may also be worth reconsidering whether Git Bash login mode should be the default first choice, since its startup cost makes timeout-related bugs much more visible.

Hope this helps. If useful, I can also provide the exact replacement pattern I used to verify the fix locally.