Add strict executable launch

[zengfanfan]

Summary

• add LaunchExecutable for launching one explicit executable path with separated argv
• accept argv as a native string list or JSON-encoded string list
• support an optional explicit working directory
• launch with shell=False and return the created PID plus normalized launch inputs
• validate the executable, working directory, and argv before process creation

Motivation

The existing App tool is convenience-oriented and resolves applications through Start Menu and
name-based workflows. Deterministic automation also needs a small path-based launch primitive that
does not use shell parsing, fuzzy matching, file associations, or Start Menu lookup.

Safety and compatibility

• the executable must resolve to an existing file
• every argv element must be a string and remains a separate process argument
• an explicit working directory must resolve to an existing directory
• standard streams are detached to DEVNULL
• the tool is marked destructive because it creates a process
• existing tools and launch behavior are unchanged

Testing

• changed-file ruff check: passed
• changed-file ruff format --check: passed
• focused LaunchExecutable tests: 6 passed
• full suite on this branch: 369 passed, 3 failed
• full suite on unmodified upstream/main: 363 passed, 3 failed
• the same three tests/test_iserror_compliance.py import failures occur on unmodified
  upstream/main

Real Windows smoke validation passed with cmd.exe /d /c exit 0: the tool returned the created PID,
the exact executable path, separated argv, and the requested working directory.

Dependencies and scope

None. This branch is based directly on current main. It intentionally excludes window discovery
and launch-time window waiting; those can remain separate from this strict process-launch primitive.

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[Jeomon]

Can you show an example use case

[zengfanfan]

Sure. A typical use case is testing a local desktop application build that has not been installed and therefore has no Start Menu entry.

For example, automation may need to launch C:\work\MyApp\dist\MyApp.exe with args ["--config", "C:\test data\qa.json"] and cwd C:\work\MyApp.

The existing App tool launches applications by fuzzy-matching their Start Menu names, and it does not accept arguments or a working directory. LaunchExecutable starts this exact build with the exact arguments. App remains the simpler choice for normally installed applications.

[Jeomon]

What is your opinion about combinig the tool you created with App tool.
like a single Tool

Can you pls try it out