Windows Smart App Control blocks the unsigned browse.exe — sign release binaries

[pstilwell90]

Summary

On Windows 11 with Smart App Control (SAC) enabled, the bundled browse binary cannot execute, which breaks every browser-driven skill (/canary, /qa, /browse, live /design-review). Please code-sign the Windows release binaries so SAC permits them.

Environment

• gstack 1.58.0.0
• Windows 11, Smart App Control: On (Enforce) — HKLM:\SYSTEM\CurrentControlSet\Control\CI\Policy\VerifiedAndReputablePolicyState = 1
• Binary: ~/.claude/skills/gstack/browse/dist/browse.exe (PE32+ x86-64)

What happens

Running the binary fails at the OS policy layer:

• Git-Bash: .../browse.exe: Permission denied (x-bits are set; not a chmod issue)
• PowerShell: Program 'browse.exe' failed to run: An error occurred trying to start process ... An Application Control policy has blocked this file.

file reports it as PE32+ executable for MS Windows, and it is unsigned.

Root cause

Smart App Control blocks unsigned / low-reputation executables. Critically, SAC has no per-file allowlist — there is no supported way for a user to make one binary an exception. The only user-side workaround is turning SAC Off, which is irreversible (Windows requires a reset/reinstall to re-enable SAC). Asking users to permanently disable a security feature to run a dev tool is not a reasonable workaround.

Impact

Any Windows 11 machine with SAC enabled (the default on many new devices) cannot use the browser-driven skills at all. bin/ shell scripts run fine — only the compiled binaries are blocked.

Ask

1. Code-sign the Windows release binaries (Authenticode), and ideally submit them for Microsoft reputation so SAC trusts them without per-machine action. This is the real fix.
2. Until signed: document the SAC limitation + fallbacks (curl-based health checks, user-driven browser QA) so Windows users aren't stuck debugging "Permission denied".

Minor secondary note

dist/browse (no .exe extension) cannot be exec'd from Git-Bash even setting SAC aside — Git-Bash won't run a PE without the .exe suffix. Only dist/browse.exe is invokable. Skills compute the binary path as dist/browse; on Windows they should prefer dist/browse.exe.

[optimization2026]

This is a release provenance problem, not just a Windows support problem.

browse.exe is a security-sensitive binary because it drives the persistent browser daemon used by QA, canary, browse, design-review, and related workflows.

If Windows Smart App Control blocks unsigned binaries, then browser-driven skills become unavailable for security-conscious Windows users.

A standard AISP-style release contract could make the binary trust requirements explicit:

[
  {
    "role": "system",
    "content": {
      "protocol": "AISP V1.0.0",
      "axiom_0": "Human_Sovereignty_and_Wellbeing",
      "id": "gstack_windows_binary_provenance_aisp",
      "name": "gstack Windows Binary Provenance Contract",
      "version": "1.0.0",
      "license": "MIT",
      "summary": "Machine-checkable contract for Windows release binary signing and provenance evidence.",
      "flow_format": "mermaid",
      "loading_mode": "node",
      "tools": ["filesystem", "shell"],
      "params": {
        "binary_path": "string",
        "release_manifest_path": "string"
      },
      "system_prompt": ""
    }
  },
  {
    "role": "user",
    "content": {
      "instruction": "STRICTLY OBEY aisp_contract; its non_negotiable rules are inviolable; then RUN aisop.main",
      "user_input": "{user_input}",
      "aisp_contract": {
        "profile": "aisp.skill.v1",
        "invocation": {
          "mode": "release_validation",
          "when_to_use": [
            "before publishing Windows release binaries",
            "before installing browse.exe on Windows",
            "when browser-driven skills depend on a native executable"
          ],
          "when_not_to_use": [
            "source-only development builds",
            "non-Windows platforms"
          ]
        },
        "non_negotiable": [
          {
            "rule": "Windows release binaries should have Authenticode signature or a documented fallback status.",
            "enforced_by": "verify_signature.step2:sys.assert"
          },
          {
            "rule": "Release manifest must include binary hash, platform, version, and signing status.",
            "enforced_by": "manifest.step2:sys.assert"
          },
          {
            "rule": "Installer must not recommend disabling Smart App Control as the normal path.",
            "enforced_by": "docs.step2:sys.assert"
          }
        ],
        "discovery": {
          "category": "release_provenance",
          "tags": ["gstack", "windows", "browse.exe", "code-signing", "provenance", "aisp"]
        },
        "risk_level": "high",
        "resources": [
          {
            "id": "binary",
            "path": "{binary_path}",
            "kind": "binary",
            "mode": "read_only",
            "when": "Read during release validation.",
            "scope": "skill"
          },
          {
            "id": "release_manifest",
            "path": "{release_manifest_path}",
            "kind": "manifest",
            "mode": "read_only",
            "when": "Read before release or install.",
            "scope": "skill"
          }
        ]
      },
      "aisop": {
        "main": "graph TD\n    hash[Compute binary hash] --> verify_signature[Verify Authenticode signature]\n    verify_signature --> manifest[Validate release manifest]\n    manifest --> docs[Validate install guidance]\n    docs --> report[Emit release validation report]\n    report --> end_node((End))"
      },
      "functions": {
        "hash": {
          "step1": "Compute sha256 for binary_path.",
          "output_mapping": "binary_sha256"
        },
        "verify_signature": {
          "step1": "Check Authenticode signature status for binary_path.",
          "step2": "sys.assert('signature valid or fallback explicitly documented', 'Windows release binary lacks valid signature or documented fallback')",
          "output_mapping": "signature_status"
        },
        "manifest": {
          "step1": "Validate release manifest includes path, platform, sha256, version, build commit, signing status, and timestamp.",
          "step2": "sys.assert('release manifest contains binary hash and signing status', 'Release manifest missing binary provenance')",
          "output_mapping": "manifest_validation"
        },
        "docs": {
          "step1": "Check Windows installation docs for Smart App Control guidance.",
          "step2": "sys.assert('docs do not recommend disabling SAC as normal path', 'Install docs should not normalize disabling Smart App Control')",
          "output_mapping": "docs_validation"
        },
        "report": {
          "step1": "Return binary hash, signature status, manifest status, and docs status.",
          "output_mapping": "release_validation_report"
        },
        "end_node": {
          "step1": "Return release_validation_report."
        }
      }
    }
  }
]

The practical fix path:

1. Authenticode-sign Windows release binaries.
2. Publish a release manifest with sha256 + signing status.
3. Add installer preflight that detects SAC block and explains signing status.
4. Avoid recommending permanent SAC disablement.
5. Provide source-build or WSL fallback documentation if signing is not immediately available.

The invariant:

browser-driven skills depend on a trusted executable;
Windows users need provenance/signing evidence, not a security downgrade workaround.