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

Activity

1. optimization2026 commented on Jun 30, 2026

   

   optimization2026

   on Jun 30, 2026

   More actions

   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.
   
2. time-attack commented on Jul 15, 2026

   

   time-attack

   on Jul 15, 2026

   Last edited by time-attack

   Contributor

   More actions

   @pstilwell90 Windows release executables remain unsigned. An Authenticode signing workflow and signed-artifact metadata are still missing.
3. capy-ai

   added 2 commits that reference this issue on Oct 8, 2026

   v1.91.60.0 fix(windows): setup degrades instead of dying on a CSO fai…

   ...

   4dfd83b

   v1.91.65.0 fix(install): skills only for the agents you installed, ev…

   ...

   b357b50
4. levi85

   added 2 commits that reference this issue on Oct 14, 2026

   v1.91.60.0 fix(windows): setup degrades instead of dying on a CSO fai…

   ...

   3af038f

   v1.91.65.0 fix(install): skills only for the agents you installed, ev…

   ...

   551dc79
5. capy-ai commented on Oct 17, 2026

   

   capy-aiBot

   on Oct 17, 2026 – with Capy AI

   Contributor

   More actions

   Thanks for the report, @pstilwell90. This is the same problem as #2595, which has the fuller diagnosis (all five compiled binaries are affected) and is where the signing work is tracked, so we're closing this as a duplicate.

   Signing is now funded and planned for the Nov 15 revisit (see #2595). In the meantime, setup and gstack-doctor detect a Smart App Control block and point at docs/troubleshooting.md instead of printing a bare "Permission denied".
6. capy-ai

   closed this as a duplicateof Windows: Smart App Control blocks browse.exe; the CLI has no Node lane (the server does) #2595 on Oct 17, 2026