Six weeks after the September 2026 Update, the useful question is not what shipped — that announcement is already covered here — but what a server operator or addon author should do with it this month. This piece takes the second pass: which channel carries which binaries today, which regressions are still open in Facepunch’s tracker, and how to move a live server without dropping the map pool players join for.
The announcement was more finished than the transition. 64-bit Windows binaries exist in the live build, the default is still on the beta side, Linux 64-bit is unfinished work in the public commit log, and the only compatibility document is a bug tracker.
What this covers: the branch and build state of Garry’s Mod on 29 October 2026, the addon-facing differences between the 32-bit and 64-bit binaries that are documented and still open, and a migration order that keeps a server’s map pool intact. Why it matters: the live build and the beta branches no longer run the same code, so two servers with the same addon collection can behave differently depending on a Steam dropdown most owners set once and forgot. Who should care: operators with a curated map pool, addon authors whose Lua touches physics, matrices or entity overrides, and anyone maintaining an install they cannot rebuild.
Where the build state actually sits
The changelist index is the cleanest record of what is live: its newest entry is the 17 September 2026 hotfix, and no October patch appears on it. Steam’s announcement feed for appid 4000 agrees — October’s entries are press coverage, not release notes. A console dump filed in a September bug report records the live client as GMod version 2026.09.17, a date-shaped scheme, not a sequential one.
| Channel | What it carries, per the sources | What it means for you |
|---|---|---|
| Default / public | September 2026 Update plus the 17 September hotfix; 64-bit builds of client, Hammer and dedicated server “available on Windows” | 32-bit unless you opt in through Steam launch options |
| Pre-Release | The next update’s changes, per the wiki changelog page, which says the update “is already accessible on the dev beta branch, and possibly on the prerelease beta branch” | Preview only; do not run a production pool on it |
| dev | “The next version of Garry’s Mod. It contains all the changes that will be included into the game in next update” | Where the forced-64-bit default and the new server addon-list file currently live |
| x86-64 | The 64-bit testing branch the 9 September announcement named alongside dev as carrying all the upcoming changes | Pre-release testing of 64-bit itself; its own version string, e.g. 2026.08.13 in one August report |
| network_test | Wiki: “changes that are not network compatible with other versions of the game, i.e. you will not be able to join existing servers on that beta” | Never mix with a live server population |
Two consequences follow. The 64-bit binaries and the 64-bit default live in different places, and the default is not shipped yet. And network_test is a real fork in behaviour, not a label — a server pinned to it cannot be joined from other versions.
The forced default is listed, not shipped
The commit that changes the default is titled “Force 64bit builds as the default” and describes the mechanism exactly: “gmod.exe now relaunches with gmod_win64.exe on 64bit systems, exactly like TF2 does”, with “-force32bit” available to keep the older client. That commit lives in the public branch log rather than the September changelist, and the log prints relative timestamps — it read “35 Days Ago” when retrieved — so it cannot be dated to the day.
What makes that citable now is the wiki. The Update Preview Changelog, which describes itself as “upcoming changes to the game in the next update”, lists under Changes: “Forced 64bit builds to be the default on Windows (-force32bit can be used on gmod.exe to force 32bit builds)”. That placement matters: the flip belongs to the next update, so an owner who does nothing this week is still on September behaviour — 64-bit available, 32-bit used unless selected.
There is a gap in the mechanism worth flagging. Both the commit and the wiki note name gmod.exe and gmod_win64.exe; neither says whether the Windows dedicated server binary relaunches the same way. Treat “my server is now 64-bit” as unverified until you read it in the server’s own console banner, and do not assume -force32bit has a server-side twin.
Which addons break, and which only look broken
There is no published compatibility list, so the honest answer is a set of documented differences. The most consequential one is arithmetic, not crashes.
| Symptom | Where it is documented | What to do |
|---|---|---|
| Matrix and vector results differ between the two binaries | Issue #6616, open since 19 November 2025: “The expected behavior is that these functions return the same values regardless of the build” | Test maths-heavy code on the exact binary your server runs |
| Native library present on one build, missing on the other | Issue #7068 (closed the day it was filed, 25 September) plus the changelist’s Holly error-handling fix | Ship both architectures if you ship native code |
| Lua overrides of built-in entities behaving differently | Issue #6996 (closed 17 August); the next update expands the override list | Do not assume a fixed override list |
| Addon content breaking a menu rather than itself | Next-update changelog: “Fixed missing data in NPC weapon list (from addons) bricking the spawnmenu” | Validate your NPC weapon tables |
| Addons failing to mount on Linux servers | 17 September hotfix: “Fixed certain addons with weird file names refusing to be mounted on Linux dedicated servers” | Rename files to plain ASCII before a Linux move |
| A failure that becomes an explicit error | Next update: “Make surface.DrawPoly throw an error when giving it less than 3 verts” | Fix degenerate polygons before the update lands |
Issue #6616 names the pattern rather than a crash. Its author lists VMatrix:GetScale() returning 1.000000 1.000000 1.000000 on 32-bit against 0.999661 0.999661 0.999661 on 64-bit after 3,000 repeated angle-and-translation sets; a Vector:Dot of identical inputs returning -135.76454544067 against -135.76452636719; and Vector:Normalize() followed by :Mul(65536) landing on 65535.996094 against 65536.000000. The report describes “glitches and server/client desync issues”, found while “working on client/server predicted collision mesh building” with “slight discrepancies between my 64 bit client and my 32 bit server that resulted in subtle movement prediction and graphical issues”.
That is the migration warning in miniature. A mixed pair — 64-bit client, 32-bit server — is supported today, because the client is selectable from launch options while the server default has not flipped. Prediction-sensitive addons are where the two halves disagree.
The Holly reports show the same shape in native code. Commit #4086f8 records “Added 64bit Holly libraries from x86-64 (and made them work)”, and the September changelist promises better handling so “The game no longer crashes (64bit builds) when Holly.dll is missing”. Issue #7068, filed 25 September against the live build and closed the same day, reports the module “missing” when running gm_video. If your addon ships a DLL, that split is yours to solve.
The clearest pre-release catch is in the commit log rather than the tracker: one commit makes a physics change “opt-in via argument”, with the reason spelled out — “This change causes infinite loops in existing addons, such as TTT.” An addon break caught before it shipped, and a reminder that “no reports” is not “no differences”.
The September changelist also removed things addons can reference, worth a grep before an update rather than after: con_logfile, the env_debughistory entity “and its associated console commands”, the point_bonusmaps_accessor entity, the CHudVoiceSelfStatus HUD element, and “SCRIPTNAME and SCRIPTPATH setting code when running Lua scripts”. The next update continues in that direction by blocking the envmap and lightprobe console commands from Lua.
Moving a server without losing the map pool
The wiki’s dedicated-server page documents two ways Workshop content reaches a server.
The established route is a collection: “Dedicated servers can install addons straight from workshop collections, but it requires an addition to the startup parameter” — +host_workshop_collection with the collection ID. Collections “can be nested, and the dedicated server will download all sub-collections as well”, so a per-map-pack sub-collection is a unit you can pin and swap. And the collection “needs to be public or unlisted, else, srcds won’t be able to access it” — the silent failure when a pool stops resolving after a privacy change.
The map handoff is automatic once the IDs are in hand: “If your server is running a map that is also in the server’s collection (by .bsp name), the map will be automatically marked for download by clients”, with Making workshop map available for client download printed to console. A map pool is, in practice, a collection whose .bsp names you control.
The second route is newer and is where the next update lands. The same wiki page documents cfg/srcds_workshop_ids.txt, “created manually”, storing explicit wsid entries and usable “in place or in addition to a workshop collection”, dated “version 2026.09.22 or newer” — later than the 2026.09.17 live client recorded in a September report. The next-update changelog lists the same capability as “Added ability to load Workshop IDs from a file on dedicated servers instead of a Steam Workshop collection”. Both sources put it on the beta side of the line, so verify it on your own srcds before planning around it; a file-based list is still the better instrument for pinning a pool, because it survives someone else editing the collection.
A workable order, using documented pieces:
- Freeze updates for the length of the move.
host_workshop_autoupdateset to0stops the server updating content at start-up. The wiki’s trade-off: disabling it “could lead to other unwanted consequences, such as map updates preventing players from joining your server (since your server would be running older version of the map)”. - Keep the collection as the source of truth, and split the pool into sub-collections before anything else changes, so the map pack has an ID independent of the server.
- Build the new install rather than copying the old one. The next-update changelog includes “Make dedicated server workshop cleanup do it in the correct folder (
cache/srcds/instead ofcache/workshop/)” — the cleanup was looking in the wrong place. An install carried over from an older box can hold content that logic has never touched; a fresh install plus the collection is reproducible in a way a copied folder is not. - Run the candidate build beside the live one. The dev-branch page describes the branch’s purpose as letting “addon developers … adjust to upcoming changes” and warns that joining normal servers works “most of the time”, except when an update is about to release. A second instance is safe; a swap-in-place is not.
- Check the version banner on both boxes; the Steam branch name and the console version string are the only two things that reliably distinguish a 32-bit server from a 64-bit one.
Linux is behind, and the commit log says so
The shipped 64-bit binaries are Windows binaries: the changelist entry reads “64-bit builds of the game client, Hammer and dedicated server are now available on Windows”, and the hotfix a day later still refers to the “native 32-bit Linux client”. Linux operators have no 64-bit path in the live build.
That is changing on the main branch, not in a release. The public commit log shows a run of Linux64 work in the commits’ own words — “LuaJIT builds for Linux64”, “gmad/gmpublish build for Linux64”, “Linux64 build progress” with ”* Dedicated server builds successfully”, “Rename hl2_linux to gmod_linux” with ”* 64bit Linux Dedicated Server runs and can be joined”, and “Linux64 bit client progress” including ”* Disable Awesomium for 64bit Linux client builds”. gmad and gmpublish are the addon-packaging and Workshop-publishing tools, so that line matters to authors, not only to hosts.
Every date in that list is relative — “Today”, “5 Hours Ago”, “3 Days Ago” — and the branch log offers no absolute ones. The only defensible statement is sequence: the Linux 64-bit dedicated server has reached a state its commit message calls joinable, the client has not, and neither appears in the changelist index. Do not plan a Linux 64-bit migration against dates.
What to change this month
- Test on the binary you deploy. If your server is 32-bit and your players run the 64-bit client, that mixed pair is what issue #6616 describes.
- Read your own Lua for removed names.
con_logfile,env_debughistory,point_bonusmaps_accessor,CHudVoiceSelfStatus, and code that expectsSCRIPTNAMEorSCRIPTPATHto be set are all gone from the live build. - Fix the quiet errors before they get loud.
surface.DrawPolywith fewer than three vertices stops being tolerated in the next update (“Makesurface.DrawPolythrow an error when giving it less than 3 verts”), andresource.AddWorkshopin the September build “bails when given empty input or input that is too short”, throwing a non-halting error underlua_strict 1. - Expect behaviour fixes to move your output. The next update’s Lua list includes “Fixed
SetNWVarProxycallback’s old value being the new value” and “Applied fixes forgetmetatable(),math.ceilandmath.floorfrom LuaJIT repository” — the kind of correction that changes results for addons that compensated for the old behaviour. - Map authors should watch the compile tools, not just the runtime. The next update raises
MAX_MAP_TEXINFO“to the new TF2 limit (16k>32k)”, lifts VBSP’s detail-sprite limit “2mil=>2bil”, applies a “T-Junction limit softcap (instead of crashing)” and adds-noTJuncsDetailfrom Team Fortress 2. A map that leans on those raised limits is tied to the builds that carry them, so test it on the live branch before it enters a pool. - Do not treat 64-bit as a superset. The next-update list contains “Fixed demo-to-video feature on 64bit Windows builds” — a defect that exists only on the newer binary.
For scale, SteamCharts’ tracker read 32,666 players at retrieval, with a last-30-days average of 22,021.30 and a peak of 38,977 — third-party estimates, but enough to say a lot of addon-heavy sessions sit behind that dropdown.
My advice assumes the live build of 29 October 2026: the September 2026 Update plus the 17 September hotfix, with 64-bit Windows binaries available and the forced default still listed as upcoming. Everything labelled “next update” comes from the wiki’s preview changelog and the dev branch, and is unshipped until it appears in the changelist index.