Two low-severity game-server packaging/script items grouped for one PR.
if $VAR = true executes the env var's value as a command, silently skipping plugin install on truthy misconfig
Location: apps/swiftly/scripts/setup.sh:125 (game-server)
What: The guards if $AUTOLOAD_PLUGINS = true ; then (line 100) and if $INSTALL_5STACK_PLUGIN = true ; then (line 125) are not test expressions: the unquoted variable expands to the first word of the command line, so bash runs the value as a command with args = true. It only works for the literal defaults true/false because those happen to be shell builtins. Any other truthy value breaks it. The same pattern is in apps/counterstrikesharp/scripts/setup.sh:97 and :110.
Impact: An operator sets INSTALL_5STACK_PLUGIN=1 (a common way to express 'enabled'). setup.sh runs 1 = true, which fails with 'command not found' (exit 127), so the then-branch is skipped and the FiveStack plugin symlink into game/csgo/addons/swiftlys2/plugins/FiveStack is never created: the entire 5Stack match-management plugin fails to load with no error explaining why. Setting a value like yes is worse, since yes = true streams output forever and hangs container startup.
Suggested fix: Use a real string test, e.g. if [ "$INSTALL_5STACK_PLUGIN" = "true" ]; then (and likewise for AUTOLOAD_PLUGINS in both apps).
Verifier evidence
apps/swiftly/scripts/setup.sh:100 if $AUTOLOAD_PLUGINS = true ; then; :125 if $INSTALL_5STACK_PLUGIN = true ; then. apps/counterstrikesharp/scripts/setup.sh:97 and :110 same pattern. Setters constrain values to literals: apps/swiftly/Dockerfile:53/56 ENV AUTOLOAD_PLUGINS=true / ENV INSTALL_5STACK_PLUGIN=true; api/src/dedicated-servers/dedicated-servers.service.ts:242-244 name: "INSTALL_5STACK_PLUGIN", value: server.type === "Ranked" ? "true" : "false". Repo-wide grep found no other setter producing values other than true/false.
Dev image pins older Metamod/CounterStrikeSharp than the production Dockerfile
Location: apps/counterstrikesharp/Dockerfile.dev:31 (game-server)
What: Dockerfile.dev sets METAMOD_URL to mmsource-2.0.0-git1374 (from mms.alliedmods.net/mmsdrop/2.0) and COUNTER_STRIKE_SHARP_URL to v1.0.369, while the production Dockerfile (lines 80-81) uses mmsource-2.0.0-git1403 (from the GitHub release) and v1.0.371. The two dependency baselines have drifted in both version and source host, so the dev container builds and runs the plugin against a different metamod/CSS runtime than production.
Impact: A developer validates a plugin change locally against CSS 1.0.369/metamod git1374 and it works, but production runs CSS 1.0.371/metamod git1403; an API/offset/behavior change between those versions (or a fix only present in the newer build) is missed in dev and surfaces only after deploy. Conversely a dev-only breakage cannot be reproduced against prod versions.
Suggested fix: Pin both Dockerfiles to the same Metamod and CounterStrikeSharp versions and source URLs (ideally via a shared build ARG) and bump them together.
Verifier evidence
Dockerfile.dev:31 ENV METAMOD_URL=https://mms.alliedmods.net/mmsdrop/2.0/mmsource-2.0.0-git1374-linux.tar.gz; Dockerfile.dev:32 ENV COUNTER_STRIKE_SHARP_URL=https://github.com/roflmuffin/CounterStrikeSharp/releases/download/v1.0.369/counterstrikesharp-with-runtime-linux-1.0.369.zip. Dockerfile:80 ENV METAMOD_URL=https://github.com/alliedmodders/metamod-source/releases/download/2.0.0.1403/mmsource-2.0.0-git1403-linux.tar.gz; Dockerfile:81 ENV COUNTER_STRIKE_SHARP_URL=https://github.com/roflmuffin/CounterStrikeSharp/releases/download/v1.0.371/counterstrikesharp-with-runtime-linux-1.0.371.zip. Both use the URLs at Dockerfile.dev:48/51 and Dockerfile:104/107 via wget -q $METAMOD_URL / wget -q $COUNTER_STRIKE_SHARP_URL.
Found by the 2026-07 multi-agent code audit; adversarially verified (CONFIRMED, P3). One of a batch of findings from that pass.
Two low-severity game-server packaging/script items grouped for one PR.
if $VAR = trueexecutes the env var's value as a command, silently skipping plugin install on truthy misconfigLocation:
apps/swiftly/scripts/setup.sh:125(game-server)What: The guards
if $AUTOLOAD_PLUGINS = true ; then(line 100) andif $INSTALL_5STACK_PLUGIN = true ; then(line 125) are not test expressions: the unquoted variable expands to the first word of the command line, so bash runs the value as a command with args= true. It only works for the literal defaultstrue/falsebecause those happen to be shell builtins. Any other truthy value breaks it. The same pattern is in apps/counterstrikesharp/scripts/setup.sh:97 and :110.Impact: An operator sets INSTALL_5STACK_PLUGIN=1 (a common way to express 'enabled'). setup.sh runs
1 = true, which fails with 'command not found' (exit 127), so the then-branch is skipped and the FiveStack plugin symlink into game/csgo/addons/swiftlys2/plugins/FiveStack is never created: the entire 5Stack match-management plugin fails to load with no error explaining why. Setting a value likeyesis worse, sinceyes = truestreams output forever and hangs container startup.Suggested fix: Use a real string test, e.g.
if [ "$INSTALL_5STACK_PLUGIN" = "true" ]; then(and likewise for AUTOLOAD_PLUGINS in both apps).Verifier evidence
apps/swiftly/scripts/setup.sh:100
if $AUTOLOAD_PLUGINS = true ; then; :125if $INSTALL_5STACK_PLUGIN = true ; then. apps/counterstrikesharp/scripts/setup.sh:97 and :110 same pattern. Setters constrain values to literals: apps/swiftly/Dockerfile:53/56ENV AUTOLOAD_PLUGINS=true/ENV INSTALL_5STACK_PLUGIN=true; api/src/dedicated-servers/dedicated-servers.service.ts:242-244name: "INSTALL_5STACK_PLUGIN", value: server.type === "Ranked" ? "true" : "false". Repo-wide grep found no other setter producing values other than true/false.Dev image pins older Metamod/CounterStrikeSharp than the production Dockerfile
Location:
apps/counterstrikesharp/Dockerfile.dev:31(game-server)What: Dockerfile.dev sets METAMOD_URL to mmsource-2.0.0-git1374 (from mms.alliedmods.net/mmsdrop/2.0) and COUNTER_STRIKE_SHARP_URL to v1.0.369, while the production Dockerfile (lines 80-81) uses mmsource-2.0.0-git1403 (from the GitHub release) and v1.0.371. The two dependency baselines have drifted in both version and source host, so the dev container builds and runs the plugin against a different metamod/CSS runtime than production.
Impact: A developer validates a plugin change locally against CSS 1.0.369/metamod git1374 and it works, but production runs CSS 1.0.371/metamod git1403; an API/offset/behavior change between those versions (or a fix only present in the newer build) is missed in dev and surfaces only after deploy. Conversely a dev-only breakage cannot be reproduced against prod versions.
Suggested fix: Pin both Dockerfiles to the same Metamod and CounterStrikeSharp versions and source URLs (ideally via a shared build ARG) and bump them together.
Verifier evidence
Dockerfile.dev:31
ENV METAMOD_URL=https://mms.alliedmods.net/mmsdrop/2.0/mmsource-2.0.0-git1374-linux.tar.gz; Dockerfile.dev:32ENV COUNTER_STRIKE_SHARP_URL=https://github.com/roflmuffin/CounterStrikeSharp/releases/download/v1.0.369/counterstrikesharp-with-runtime-linux-1.0.369.zip. Dockerfile:80ENV METAMOD_URL=https://github.com/alliedmodders/metamod-source/releases/download/2.0.0.1403/mmsource-2.0.0-git1403-linux.tar.gz; Dockerfile:81ENV COUNTER_STRIKE_SHARP_URL=https://github.com/roflmuffin/CounterStrikeSharp/releases/download/v1.0.371/counterstrikesharp-with-runtime-linux-1.0.371.zip. Both use the URLs at Dockerfile.dev:48/51 and Dockerfile:104/107 viawget -q $METAMOD_URL/wget -q $COUNTER_STRIKE_SHARP_URL.Found by the 2026-07 multi-agent code audit; adversarially verified (CONFIRMED, P3). One of a batch of findings from that pass.