Build log
Toolshape Voice: shipping a launcher the OS is trying to block
The workstation's application-control policy blocks newly compiled unsigned executables. Notes on shipping a desktop entry point that works with the policy instead of around it.
Source: Public repository: chasedndt/toolshape-voice
Context#
Toolshape Voice needed a double-clickable operator entry point on a Windows machine running an enforced application-control policy. The original design generated a small wrapper executable at build time.
Problem#
The policy blocks newly compiled unsigned executables — correctly, since that is exactly what malware looks like. Every fresh build produced a wrapper the OS refused to run. The naive fixes (disable the policy, sign ad hoc, whitelist a build directory) all weaken the machine to make the tool convenient.
Decision#
Stop generating wrappers entirely. The packaged application itself becomes the launch target, with Desktop and repo-root shortcuts regenerated by the packaging step, and a dedicated launcher test that verifies the exact shortcut target, an isolated authenticated launch, and a real Explorer launch with zero matching Code Integrity blocks.
Lessons#
Security policy is an environment constraint, not an obstacle. Designs that fight the policy create support burden forever; designs that treat 'launches cleanly under enforcement, with proof' as an acceptance test get more trustworthy over time, not less.
Current status#
Packaged build and shortcuts in daily use. Production signing remains deferred and is listed as such in the repository.