The macOS x64 installer job in the Publish workflow fails intermittently at the Create Application Server Installer step. When it fails, conda pack aborts like this:

$ conda pack -p ./env_installer/jlab_server -o ./env_installer/jlab_server.tar.gz
rosetta error: unable to mmap __TEXT: 84
 .../_csv.cpython-311-darwin.so.aot/bin/sh: line 1: 25563 Abort trap: 6   conda pack ...
error Command failed with exit code 134.

The install and the extras copy just before it succeed, so it is only the pack step that dies, with a rosetta error and Abort trap: 6 (exit 134).

I think the cause is the runner image move rather than anything in our scripts. macos-latest is migrating to macOS 26 on Apple Silicon (actions/runner-images#14167), so the runner is arm64 now. The osx-64 matrix leg installs an x86_64 conda environment, and conda pack runs that environment's x86_64 Python, which means it executes under Rosetta on an arm64 host. The unable to mmap __TEXT abort looks like a Rosetta translation flake. The two other errors on the same job, the runner's own System.IO.IOException: Illegal byte sequence in PagingLogger, and the Can't find action.yml on the post-run checkout cleanup, both happen after that abort, which also seems to be why the job logs come back empty (BlobNotFound) when you try to read them.

It is intermittent: the same step passes on other runs, and only the osx-64 leg is affected. The osx-arm64 leg builds an arm64 environment so its Python runs natively and does not hit this.

One option that would remove the Rosetta path entirely is to pin just the osx-64 row to a native Intel runner. GitHub still offers macos-26-intel (and macos-15-intel) as x86_64 images; there is no macos-latest-intel, since -latest stays arm64. macos-26-intel is the newest, so it tracks macOS 26 like the arm64 legs. Something like:

- { platform: osx-64, platform_name: macOS x64, os: macos-26-intel, build_platform: osx-64, conda_platform: osx-64 }

leaving the arm64 leg on macos-latest. Worth noting x86_64 macOS runners go away in Fall 2027, so the osx-64 installer will need a longer term plan around then regardless (cross-arch pack, or dropping the Intel build). A short term alternative is just re-running the failed job, since it is flaky.

Happy to send a PR pinning the osx-64 leg to macos-15-intel if that direction sounds right.

Failing run for reference: https://github.com/jupyterlab/jupyterlab-desktop/actions/runs/28604550262

I traced the log chain with Claude Code and confirmed the runner image move and the Intel runner timelines myself before writing this up.