[borzaka]

Description

The GSLT entered during install is stored as gslt in the cs2server LinuxGSM config, but the cs2server startparameters never passed it on. The server logged into an anonymous game server account and only accepted LAN connections (No Steam account token was specified ... Connections will be restricted to LAN only).

This adds +sv_setsteamaccount ${gslt} after +exec ${selfname}.cfg. The order matters: the CS2 game server config template sets sv_setsteamaccount "", which clears a token given before it. When gslt is empty, the command only prints its usage line, so servers that set the token in the game server config keep working.

Fixes #5106

Affected servers: cs2

Type of change

• Bug fix (a change which fixes an issue).
• New feature (a change which adds functionality).
• New Server (new server added).
• Refactor (restructures existing code).
• Chore (CI, workflows, tooling or other maintenance).
• Comment update (typo, spelling, explanation, examples, etc).

Testing

• Commands/tests run: on a fresh cs2server install, set startparameters in the instance config to each order, ran ./cs2server start and checked the console log with grep -E "logon token|anonymous game server|already logged into steam|Usage: sv_setsteamaccount" log/console/cs2server-console.log.
• Result:
  • Token in gslt, +exec ${selfname}.cfg +sv_setsteamaccount ${gslt} (this PR): Logging into Steam gameserver account with logon token 'XXXXXXXX...'.
  • Token in gslt, +sv_setsteamaccount ${gslt} +exec ${selfname}.cfg: anonymous login, because the game server config line sv_setsteamaccount "" cleared the token.
  • gslt="", token only in the game server config, order of this PR: Usage: sv_setsteamaccount <login_token>, then Logging into Steam gameserver account with logon token 'XXXXXXXX...'.
  • Before this change, with the token only in gslt: anonymous login, LAN only.
• Environment used (distro/version): Debian GNU/Linux 12.15 (bookworm) x86_64, fresh cs2server install, CS2 build current on 2026-10-26.

Risk and rollback

• Risk level: low
• Rollback plan: revert this commit.

Breaking changes

• No breaking changes.
• Breaking changes included (describe below).

Documentation

• No documentation update required.
• User documentation update required (LinuxGSM-Docs).
• Developer documentation update required (LinuxGSM-Dev-Docs).

Checklist

PR will not be merged until all steps are complete.

• This pull request links to an issue ("Fixes", or "Related to" for a partial fix).
• This pull request uses the develop branch as its base.
• This pull request subject follows the Conventional Commits standard.
• This code follows the style guidelines of this project.
• I have performed a self-review of my code.
• I have provided a detailed enough description of this PR.

---

🤖 Generated with Claude Code

[dgibbs64]

Thanks for this, and for the detailed write-up in the issue. I tested the change on a test server and it does what it says: the token reaches the server, an empty gslt still starts fine, and a token set only in the game server config still works.

It has also highlighted a bigger issue I need to sort out. LinuxGSM handles the GSLT inconsistently across servers: most pass it as a start parameter, a few keep it in the game server config, a couple do both, and some ask for a token at install and then never use it. I’d like to move tokens into the game server config wherever the game supports it, with a migration path so existing servers that use gslt= keep working.

Adding a start parameter to cs2 would move it in the opposite direction, so I’m going to hold off merging this while I work out the wider approach. Thanks again for digging into the history on this one, its highlighted the larger issue.

[borzaka]

Thanks for testing it. Before you settle on the direction, I'd argue for the opposite move: keep the GSLT as a start parameter everywhere. That is how the official docs describe it, and it needs no migration.

• Valve puts it on the command line. The CS2 dedicated server page says "include it in your launch parameters with +sv_setsteamaccount <TOKEN>", and the reference launch line in the Major supplemental rulebook is ./cs2 -dedicated ... +map de_dust2 +sv_setsteamaccount TOKEN .... The same rulebook sets the gameplay convars from the gamemode configs, so config files hold the game settings and the token goes on the command line.
• So do the LinuxGSM docs. The GSLT page describes gslt= as a variable "that gets added to the start parameter", the installer tells users to change it in the LinuxGSM config, and secrets-<instance>.cfg already gives the token a private place. Most servers already work this way (13 of the 18 with a gslt= variable, see the table below).
• The command line is the only place that is always early enough. The token is read once, when the server logs in to Steam. A game server config is only early enough if it runs before that: +exec works (test C in [Bug]: cs2server ignores the GSLT entered during install #5106), but a config loaded with +servercfgfile runs when the map loads, and CS2 warns when the token comes too late (You need to use the sv_setsteamaccount command earlier). A config can also clear the token: sv_setsteamaccount "" wiped a token set before it (test B), and the bb2, bmdm and cs2 templates all have that line.
• No migration needed. Existing gslt= values keep working, and adding the parameter where it is missing is backward compatible: in CS2 a token set only in the game server config still works with it (test C). Moving tokens into game server configs would mean copying gslt= into files that users have already edited, on every server, after checking per engine that the config runs early enough.
• Hosting panels and Docker images do the same. The Pelican CS2 egg, joedwards32/CS2 and kus/cs2-modded-server all put +sv_setsteamaccount in the launch command, which the host controls, while users edit the game server config.

My suggestion: keep gslt= as a start parameter everywhere, add it where it is asked for but not used (cs2 with this PR, em and zps), and remove sv_setsteamaccount "" from the bb2, bmdm and cs2 templates so it cannot clear the token. Your call of course, I'm happy to help with either direction.

GSLT handling on develop

Server	gslt=	Start parameter	Game server config template
bb2, bmdm	yes	yes	sv_setsteamaccount ""
unt	yes	yes (-gslt)	Login_Token in Config.json
bs, csgo, css, dys, gmod, ins, inss, nmrih, tf2, tf2c	yes	yes	–
cs2	yes	–	sv_setsteamaccount ""
tu	yes	–	SteamLoginToken in TowerServer.ini
bo, em, zps	yes	–	– (asked at install, never used)