Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

agmsgd (v1.6.0-rc.1): Windows Task Scheduler flag conversion and bash.exe resolution (isolated tests)

Open
  • Is something wrong?
#1,609 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
bash
Domain
devops

Research direction

Start in scripts/daemon.sh at the _register_windows function, which builds the schtasks /Create call and the task XML whose Command is bash.exe. Reproduce on native Windows from Git Bash: check whether /Create is mangled into a path, and which bash.exe the scheduled task launches. Done when a test task registers without error and starts Git for Windows' bash rather than System32's. This needs a Windows machine because WSL and System32 resolution are involved.

Written by the indexing model from the issue text.

Description

Using the Windows registration code from upstream v1.6.0-rc.1 (54d6e24), I observed two issues in isolated checks on native Windows.

I could not reach this code through agmsg daemon enable itself because it stopped earlier at the install-generation check; see #1608. The checks below are not an end-to-end reproduction of enable.

Related: #1529.

Environment

Windows 11 (10.0.26300.9457), Git for Windows 2.54.0 (GNU bash 5.3.9), and WSL 3.0.3 with a distribution installed.

1. /Create was converted to a path when called from Git Bash

I extracted rc.1's _register_windows function and invoked it from Git Bash, changing only the task name to a unique test name.

It failed before registering the task:

ERROR: Invalid argument/option - 'C:/Program Files/Git/Create'.

The /Create option had been converted to a filesystem path by MSYS argument conversion.

2. A separate task using bare bash.exe launched System32's bash.exe on this machine

The task XML in rc.1 uses:

<Command>bash.exe</Command>

I registered a separate test task through the Task Scheduler COM API with Action.Path = 'bash.exe' and a trivial command, then started it.

CIM observations showed C:\Windows\System32\bash.exe running, and wsl.exe / wslhost.exe appeared.

In an interactive shell, Get-Command bash.exe -All listed Git's bash first, followed by System32's and WindowsApps' entries. I did not investigate why the task resolved a different executable.

This checked executable resolution for a separate task, not an end-to-end launch of agmsgd.

Possible directions — not tested

Possible directions are excluding the schtasks option prefixes from MSYS argument conversion, for example with MSYS2_ARG_CONV_EXCL, while keeping the XML path usable by native schtasks; and using an absolute Git Bash path in the task action.

I have not tested either change.

Scope and cleanup

I have not rerun these checks on integration/agmsgd-beta (95a2bf2). Source inspection only: <Command>bash.exe</Command> and the /Create invocation are unchanged at that commit.

Cleanup: two test tasks were deleted, and the processes I could observe had exited. Short-lived processes between samples and processes inside the WSL guest were not tracked.

Source:
https://github.com/fujibee/agmsg/blob/54d6e24e6c0d559eada7557867caaecb0935ca9e/scripts/daemon.sh

(Drafted with AI assistance — Claude Code.)

Dominant language
Shell
Stars
1.5k
Forks
156
Avg merge
19h 30m
Merged PRs (30d)
212

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from fujibee/agmsg

All issues in fujibee/agmsg

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.