[Bug] `downloadCoreTools` fails with `ENOENT: chmod 'gozip'` because current Core Tools releases no longer ship `gozip`

src/core/func-core-tools.ts の downloadCoreTools() から始め、~/.swa/core-tools を削除した後、記載されている npx コマンドで再現します。展開された Core Tools に func は含まれるが gozip は含まれない場合でも起動に成功することを、既存の権限処理を維持したまま確認します。

Before filing this issue, please ensure you're using the latest CLI by running swa --version and comparing to the latest version on npm.

I am using @azure/static-web-apps-cli 2.0.10, which is the latest version on npm at the time of writing.

Are you accessing the CLI from the default port :4280 ?

• No, I am using a different port number (--port) and accessing the CLI from that port
• Yes, I am accessing the CLI from port :4280

(Note: the failure occurs during startup, before the emulator begins listening, so the port is not a factor in this bug.)

ℹ️ NOTE: Make sure to enable debug logs when running any swa commands using --verbose=silly

Welcome to Azure Static Web Apps CLI (2.0.10)
Getting config file options from "swa-cli.config.json"...
Config file does not exist at "swa-cli.config.json"
***********************************************************************
* WARNING: This emulator may not match the cloud environment exactly. *
* Always deploy and test your app in Azure.                           *
***********************************************************************
Checking if localhost:4280 is accepting TCP connections...
Port 4280 is available. Use it.
Resolved port number: 4280
appDevserverUrl provided, we will try connect to dev server at .
Api Folder found: /home/<user>/<project-root>/api
Trying to read workflow config with values:
 - appLocation: /home/<user>/<project-root>
 - outputLocation: http://localhost:<dev-server-port>
 - apiLocation: /home/<user>/<project-root>/api
Found a SWA workflow file: /home/<user>/<project-root>/.github/workflows/azure-static-web-apps-<name>.yml
Error reading workflow configuration:
missing property "jobs.build_and_deploy_job" in the SWA workflow file "/home/<user>/<project-root>/.github/workflows/azure-static-web-apps-<name>.yml".
See https://docs.microsoft.com/azure/static-web-apps/build-configuration?tabs=github-actions#build-configuration for more information.
✖ Failed to download Functions Core Tools v4.
✖ Error: ENOENT: no such file or directory, chmod '/home/<user>/.swa/core-tools/v4/gozip'
Error: ENOENT: no such file or directory, chmod '/home/<user>/.swa/core-tools/v4/gozip'
    at Object.chmodSync (node:fs:2050:11)
    at downloadCoreTools (file:///home/<user>/.npm/_npx/<hash>/node_modules/@azure/static-web-apps-cli/src/core/func-core-tools.ts:257:8)
    at processTicksAndRejections (node:internal/process/task_queues:104:5)
    at getCoreToolsBinary (file:///home/<user>/.npm/_npx/<hash>/node_modules/@azure/static-web-apps-cli/src/core/func-core-tools.ts:290:5)
    at start (file:///home/<user>/.npm/_npx/<hash>/node_modules/@azure/static-web-apps-cli/src/cli/commands/start/start.ts:182:26)
    at Command.<anonymous> (file:///home/<user>/.npm/_npx/<hash>/node_modules/@azure/static-web-apps-cli/src/cli/commands/start/register.ts:75:7)
    at Command.parseAsync (/home/<user>/.npm/_npx/<hash>/node_modules/commander/lib/command.js:935:5)
    at run (file:///home/<user>/.npm/_npx/<hash>/node_modules/@azure/static-web-apps-cli/src/cli/index.ts:98:3) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'chmod',
  path: '/home/<user>/.swa/core-tools/v4/gozip'
}
✖ 
Could not find or install Azure Functions Core Tools.
Install Azure Functions Core Tools with:
  npm i -g azure-functions-core-tools@4 --unsafe-perm true
See https://aka.ms/functions-core-tools for more information.

Describe the bug

When swa start is run with --api-location, the CLI calls getCoreToolsBinary(), which downloads Azure Functions Core Tools if no usable installation is found. After the package is downloaded and unzipped successfully, downloadCoreTools() (src/core/func-core-tools.ts) unconditionally runs chmodSync on a file named gozip on Linux/macOS. Current Core Tools releases no longer include gozip, so the call throws ENOENT and the entire startup fails — even though the func binary itself was downloaded and extracted correctly.

Root cause details are in Additional context below.

To Reproduce

Steps to reproduce the behavior (minimal reproduction — the failure is independent of any project contents, because it happens inside downloadCoreTools before the API is ever started):

1. Use a Linux x64 machine (Ubuntu, Node.js v24) where the func binary is not detected globally
2. Remove any cached Core Tools: rm -rf ~/.swa/core-tools
3. Create an empty directory to pass as the API location: mkdir -p app api
4. Run: npx @azure/static-web-apps-cli@2.0.10 start ./app --api-location ./api
5. The CLI attempts to download Functions Core Tools v4 and fails with ENOENT: no such file or directory, chmod '~/.swa/core-tools/v4/gozip'

Expected behavior

• Startup should succeed as long as func itself was downloaded and extracted correctly, even if gozip is absent. For the local development scenario covered by swa start, gozip was a packaging/deployment helper and should not be required.
• At minimum, the code should check whether the file exists (e.g. fs.existsSync) before calling chmodSync, and skip (or log a warning) if it does not.

Screenshots

N/A — see the error log above.

Desktop (please complete the following information):

• OS: Ubuntu (Linux x64)
• Node.js: v24.18.0
• @azure/static-web-apps-cli: 2.0.10
• azure-functions-core-tools (installed via npm, for reference): 4.13.0

Additional context

Root cause (investigated):

gozip is no longer included in current azure-functions-core-tools releases — neither in the npm distribution (4.13.0) nor in the full linux-x64 archive (4.12.1) downloaded directly from GitHub Releases. I inspected the extracted archives: there is no file named gozip; instead they ship System.IO.Compression.ZipFile.dll (the standard .NET compression library). It appears the Core Tools team replaced the external Go binary (gozip) used for packaging with the standard .NET library.

However, downloadCoreTools still assumes gozip exists and chmods it unconditionally on Linux/macOS (current main, src/core/func-core-tools.ts):

  // Fix permissions on MacOS/Linux
  if (os.platform() === "linux" || os.platform() === "darwin") {
    fs.chmodSync(path.join(dest, "func"), 0o755);
    fs.chmodSync(path.join(dest, "gozip"), 0o755); // <-- throws ENOENT
  }

Suggested fix:

Guard the chmodSync call on gozip with an existence check:

const gozipPath = path.join(dest, "gozip");
if (fs.existsSync(gozipPath)) {
  fs.chmodSync(gozipPath, 0o755);
}

Related issue:

#899 is a past case where the download flow broke because assumptions about the distribution feed/artifacts no longer held (Windows, missing size: "full" artifact). This report is a different, newer cause: the removal of gozip itself from the shipped artifacts.

Workaround:

Skip the automatic Core Tools startup entirely: start Azure Functions Core Tools separately with func start, then connect the SWA CLI to it:

swa start <app-url> --api-devserver-url <local-api-url>

This corresponds to the "Manual start" flow in the official docs and does not go through downloadCoreTools, so it is unaffected by this bug.