Fix Linux Modding Detection (plus ci changes)

[auggeeo]

Fixes #379
This pull request fixes mod detection on linux! (both with among us non sandboxed and flatpaked)
also changes windows server from 2025 to 2022 for github actions so building still works (as well as adding a python dep so it builds)
also merge and push when accepted

[pxsp]

this peak

[auggeeo]

ignore the large amount of commits if merging i would say squash and merge i was too lazy to download and didn't have enough space

[greluc]

I went through this in some depth because #379 is a real annoyance, and I think there are a few things worth raising before it lands. I could not test on Linux — no machine to try it on — so everything below is read out of the sources rather than observed, and I would be glad to be shown wrong on the first point.

The path may already contain what the fix prepends

getProcessPath on Linux goes to module::getFilePath in memoryjs (lib/linux/module.cc:126):

char* module::getFilePath(pid_t processId)
{
  char *path = new char[150];
  sprintf(path, "/proc/%d/cwd", processId);
  readlink(path, path, 150);
  sprintf(path, "%s/%s", path, get_process_name_by_pid(processId));
  return path;
}

It already reads the cwd symlink and returns an absolute host path such as /home/u/.steam/steam/steamapps/common/Among Us/Among Us.exe. Prepending /proc/<pid>/cwd to that gives

/proc/1234/cwd/home/u/.steam/steam/steamapps/common/Among Us/Among Us.exe

which the kernel resolves as <cwd>/home/u/... — a subtree that will not exist. readPluginFiles then fails its fs.existsSync check on winhttp.dll, returns [], and getInstalledMods falls back to modList[0], i.e. vanilla. If it does work on your machine, I would really like to know what getProcessPath returns there, because that would mean I have misread this.

Also: if the Flatpak case is about reaching into another mount namespace, cwd is not the entry point for that. An absolute path from inside a namespace resolves through /proc/<pid>/root/...; /proc/<pid>/cwd only helps for a path relative to the working directory.

The root cause looks like it is in memoryjs, which is @OhMyGuus' own fork

Look again at those three lines. readlink(path, path, 150) reads the symlink into the same buffer it just read the path from, and readlink does not NUL-terminate. So:

• if the target is shorter than "/proc/<pid>/cwd", the result is the target followed by leftover bytes — /home/u/g + 45/cwd → /home/u/g45/cwd;
• if it is longer, there is no terminator at all and the following sprintf reads past the allocation.

That next sprintf(path, "%s/%s", path, ...) also has overlapping source and destination, which is undefined behaviour, and can overrun the 150-byte buffer. The allocation is never freed.

memoryjs is pinned as github:OhMyGuus/memoryjs#v0.0.10, so this is fixable at the source. A corrected getFilePath — separate buffers, honour the readlink return value, terminate explicitly — would fix mod detection for every Linux user without a client-side special case, and would explain #379 better than anything in this diff does.

The CI changes look superseded

This PR was opened against a nightly on Node 16.14.2, where node-gyp needed distutils. Nightly is on Node 24 now and still uses windows-latest, and it builds — the Windows leg of a PR I have open passed today in 5m48s. So:

• windows-latest → windows-2022 would move a working job onto an older image for a failure that no longer reproduces, and runner images get retired on a schedule, so it breaks again later.
• Install Python Dependencies has no matrix guard, unlike Install Linux dependencies right above it. It therefore also runs on ubuntu-latest, where python -m pip install setuptools against the system interpreter is refused on 24.04 images with error: externally-managed-environment (PEP 668). That would fail the Linux job before it reaches yarn install. It also runs when the node cache hits, where yarn install — and so node-gyp — is skipped entirely.

A rebase on current nightly would probably let both CI changes be dropped.

Smaller things

/proc/<pid>/... in this.gamePath is only valid while that process lives, where the field previously held a stable path; today the only reader runs on the next line, so nothing notices yet. And the template has no separator between cwd and the returned value, so it quietly depends on the callee returning a leading /.

---

None of this is meant to discourage the change — the bug is real, it has been open a year, and you are the only person who has gone after it. I just think the fix wants to be one level down, in memoryjs.

Disclaimer: this review was produced with AI assistance (Claude Code). Every code citation above was checked against the actual sources in this repository and in the pinned memoryjs fork, and the CI claim against a live workflow run — but as noted, none of it was executed on Linux, which is exactly where it matters. Treat it as a careful reading, not a test result.

🤖 Generated with Claude Code