Don’t Starve Together Console Commands and Admin Commands
The Don’t Starve Together console commands a server admin actually needs: getting admin rights without a password, kicking and banning by KU ID, rolling back a bad day, reviving friends and cleaning up lag, plus why commands so often do nothing on a server with caves.
Remote: sends the command to the server. Local: changes only your client. If the world does not change, check the prefix before you check the syntax.
With caves enabled, Master and Caves are separate servers. A command only runs on the shard you sent it to, and season changes belong on Master.
In a dedicated terminal, player commands can fall through to AllPlayers[1]. Use c_listallplayers() and pass the player explicitly when it matters.
c_save(), c_rollback(count) and c_shutdown(false) solve more real admin problems than world regeneration ever will.
Open the console and check Remote or Local before you type anything
The default console key is ~, the key under Esc on UK and US keyboards. You can rebind it in Controls. The console is on by default through console_enabled under [MISC], and the old launch flag is deprecated: [WARNING] -console has been deprecated: Use the [MISC] / console_enabled setting instead.
The important part is the prefix at the start of the console line. It will say Remote: or Local:. While the console is open, pressing Ctrl toggles between them.
Remote:sends the command to the server you are connected to. This is what you want for almost all admin work.Local:runs the command only in your own game client. If you spawn, move or change something here, the server does not take it as an admin action.
Remote mode is only offered when you are a client who is also an admin of that server. If you are an admin and you are in game, the console starts in Remote mode. If you never see Remote:, stop there and fix admin rights first; the command syntax is probably not the real issue.
Know where to type: in-game Remote, Local, or the shard’s own console
Use this route map when you are deciding where a command should go.
| Where you type | Best for | What it affects | Main catch |
|---|---|---|---|
In game, Remote: | Most admin work, especially player help and cursor-based commands | The shard your character is currently in | If you are standing in Caves, the command runs in Caves, not on Master |
In game, Local: | Almost never for server admin | Your own client only | Looks like a command ran, but the server world does not change |
| Dedicated server terminal or panel console for Master | Save, shutdown, moderation by KU ID, world control on Master | Master shard | Player-targeted shortcuts can hit AllPlayers[1]; no mouse cursor exists here |
| Dedicated server terminal or panel console for Caves | Shard-specific checks and commands inside Caves | Caves shard | Changing seasons here is the wrong place; Master owns season state |
| Client-hosted world | Small friend groups where the host is present | The world you are hosting | You are the server, so your commands run directly, but everyone still depends on your session staying up |
On a dedicated server, commands typed into that shard’s own console appear in the log as ConsoleInput: "...". That is useful when you need an audit trail for moderation or shutdown work.
The other catch is who the game thinks “the console player” is. Many shortcut commands act on the selected player, else ThePlayer, else AllPlayers[1]. In a dedicated terminal there is usually no selected player and no ThePlayer, so a command like c_godmode() can affect the first player in the shard list. If you mean a specific person, pass them explicitly, such as c_godmode(AllPlayers[2]).
Cursor commands need a character with a mouse. c_spawn("prefab", count), c_move(AllPlayers[n]), c_gatherplayers() and c_teleport(x,y,z) are practical in Remote mode from inside the game. They are not practical from a server terminal because there is no cursor position to read.
With caves enabled, remember that you are running two servers. A command only runs on the shard you send it to. Seasons are owned by Master, which pushes season data to secondary shards, so do season work on Master and let Caves follow.
Getting admin rights: there is no admin password in DST
There is no admin password in Don’t Starve Together. Admin access comes from adminlist.txt, using Klei user IDs in the KU_XXXXXXXX format, one ID per line. Put the file in the cluster folder, the same place as cluster.ini; on a dedicated server that is typically the server folder itself, such as MyServer/adminlist.txt. After editing the file, restart the server.
adminlist.txt KU_XXXXXXXX KU_YYYYYYYY
The host of a client-hosted world is admin automatically. On a dedicated server, anyone not in adminlist.txt is just a normal client, so they will not get Remote: admin execution.
Players can find their KU ID from the Account Info button on the main menu. You can also pull KU IDs from c_listplayers() and c_listallplayers(). Use the KU ID, not a Steam ID.
The same folder can also hold whitelist.txt and blocklist.txt. whitelist.txt is for reserved slot use with whitelist_slots; blocklist.txt stores bans. If you want to confirm the files loaded on startup, the logs show OnLoadPermissionList for blocklist.txt and adminlist.txt, and OnLoadUserIdList for whitelist.txt.
Find the right player first, then use the mildest moderation command that will work
Find the player index and KU ID
c_listplayers() prints the currently connected clients as [index] (KU_id) name <character>, with a * before admins. On a dedicated server it skips the server itself. c_listallplayers() prints the AllPlayers table for players spawned in that shard, which is what you need if you want to target AllPlayers[n] accurately. For quick head counts, use c_getnumplayers() and c_getmaxplayers().
c_listplayers() *[1] (KU_XXXXXXXX) PlayerOne <wilson> [2] (KU_YYYYYYYY) PlayerTwo <wendy> c_listallplayers() [1] (KU_XXXXXXXX) PlayerOne <wilson> [2] (KU_YYYYYYYY) PlayerTwo <wendy>
AllPlayers[n] is the player entity for that shard, and AllPlayers[n].userid gives the KU ID. That is safer than guessing from names when two people use similar display names.
Moderation commands that solve real server problems
Use this ladder when you need to stop disruption without doing more damage than necessary.
c_announce("message") puts a server message on everyone’s screen.TheNet:Kick("KU_…") or /kick removes the player; they can rejoin.TheNet:BanForTime("KU_…", 120) for a cooling-off period, TheNet:Ban("KU_…") for good.c_listplayers() first. Admins cannot be kicked or banned with the built-in tools.| Command | What it does | When to use it | Notes |
|---|---|---|---|
c_announce("message")c_announce("message", 300)c_announce() | Sends a server announcement, optionally repeating; empty call cancels the repeating one | Warnings, restart notices, “stop that now” before stronger action | Low impact. Good admin hygiene before a rollback or shutdown |
/kick / /bootTheNet:Kick("KU_xxxx") | Removes a player from the server | Immediate removal without a lasting ban | Slash kick can be voted. Admins cannot be kicked through the built-in tools, and you cannot target yourself |
/ban [seconds]TheNet:Ban("KU_xxxx")TheNet:BanForTime("KU_xxxx", seconds) | Bans permanently or for a fixed time | Griefing, harassment, repeat disruption | Bans are stored in blocklist.txt. Temporary bans are useful when you need a cooling-off period without making it permanent |
c_despawn(AllPlayers[n])c_despawn("KU_xxxx") | Despawns a player and returns them to character select | Letting someone change character, or removing a bugged character state | They lose that character and pick again, so use it for character changes or a broken character, never as a warning |
/stopvote / /veto | Stops an active vote | Bad-faith vote-kick or a mistaken rollback vote | Admin only |
TheNet:Kick("KU_XXXXXXXX")
TheNet:Ban("KU_XXXXXXXX")
TheNet:BanForTime("KU_XXXXXXXX", 120)
TheNet:Kick(AllPlayers[1].userid) The built-in scoreboard on Tab also exposes kick and ban buttons, which is often quicker than typing when a griefer is active. A vote-kick that passes bans the player for 10 minutes. Votes time out after 30 seconds, need at least 3 voters to pass, and the server must have been up for 20 seconds. That makes vote-kick a social tool for public groups, but not a replacement for proper admin access.
Save, roll back and shut down safely
These commands are the recovery set. They matter because they touch the server’s saved world state on disk, not just what one player sees. A good rule is simple: save before risky admin work, roll back only as far as needed, and shut down without saving only when the current state is the problem.
The game keeps snapshots, one per save, with an autosave at the end of each in-game day. max_snapshots defaults to 6 in cluster.ini under [MISC], so that is your normal step-back window. Before destructive work, back up and transfer your DST world. If the mess started after a server mod change, fix the mod setup instead of wiping the cluster; our guide to installing mods on a DST server covers the file side.
Use this save-history view if you are not sure how far back each rollback step really goes.
| Command | What it does | When to use it | Notes |
|---|---|---|---|
c_save() | Saves immediately | Before c_removeall("prefab"), moderation cleanup, or planned shutdown | Creates a known recovery point on disk |
c_rollback(count) | Rolls back the current world by the requested number of saves | Undoing a bad in-game day, grief, or broken cleanup step | c_rollback(1) returns to the latest save, as long as it is more than 30 seconds old; that is usually the start of the current day |
c_rollback(0)c_reset() | Restarts from the last save, discarding everything since | You want to drop unsaved recent changes without stepping back a whole extra save | Useful when the live state is bad but the last snapshot is fine |
c_shutdown()c_shutdown(false) | Shuts down with save by default; false shuts down without saving | Normal maintenance, or stopping before a bad live state is written out | false is deliberate damage control, not your normal restart path |
/rollback [numsaves] | Starts an admin rollback or a rollback vote | When you need a visible, shared rollback process | Players see Should we rollback this world?and, if it passes, Rolling server back in 5 seconds… |
c_regenerateworld()/regenerate | Permanently deletes and regenerates worlds | Only when you truly want a brand new world | Not a fix. It destroys progress, and it will not work properly for any shard that is offline or in a loading state |
c_save() c_rollback(0) c_rollback(1) c_rollback(2) c_shutdown(false)
The catch that wastes the most time is counting saves. The world saves at the end of every in-game day, so c_rollback(1) only takes you back to the start of the current day. If the damage happened yesterday, you need c_rollback(2), and each extra step goes one more day back, up to the six snapshots kept by default.
Help players without turning the whole server into a cheat session
When you are solving a live problem for one person, the right target matters more than the command itself. Remote mode in game is usually safest because your character and cursor exist, so the game knows who “you” are and where “here” is. From a dedicated terminal, pass the player explicitly whenever the command allows it.
| Command | What it does | When to use it | Notes |
|---|---|---|---|
c_godmode(player)c_supergodmode(player) | Toggles invincibility; if the player is a ghost, revives them. c_supergodmode(player) also fills stats | Emergency revive after a server-side issue or admin error | On a ghost, c_godmode(player) prints Reviving <name> from ghost. |
c_sethealth(n)c_setsanity(n)c_sethunger(n)c_settemperature(n)c_setmoisture(n) | Sets a stat to a fraction from 0 to 1 | Repairing a player after a bug, bad teleport, or failed revive follow-up | Acts on the console player and does nothing on a ghost |
c_maintainall(player)c_cancelmaintaintasks(player) | Keeps core stats topped up until cancelled | Short supervised rescue, testing a stuck condition, or stabilising someone during admin work | Good for troubleshooting; cancel it when finished so normal survival state returns |
c_goto(AllPlayers[n])c_move(AllPlayers[n])c_gatherplayers()c_teleport(x,y,z) | Teleport you, move one player, gather everyone, or teleport by coordinates | Rescuing someone stuck, regrouping after a shard issue, moving a player out of bad terrain | c_move(AllPlayers[n]) and c_gatherplayers() need your cursor, so use Remote mode in game |
/rescue | Returns a stuck player from the void to land | First response for “I fell into nothing” reports | The built-in description is If you ever find yourself stuck in the void, this will put you back on land. |
c_give("prefab", count)c_spawn("prefab", count) | Gives items to the console player or spawns them at the cursor | Replacing losses caused by server problems when rollback would be too broad | Prefab names are internal lower-case names such as "log", "goldnugget" and "beefalo" |
c_freecrafting(player)c_speedmult(n) | Unlocks all recipes for a player; changes the console player’s movement speed multiplier | Administrative testing only | Not normal recovery tools |
These commands do not cost much in server resources by themselves. The risk is administrative, not performance-related: you can affect the wrong player, move everyone on the shard, or paper over a bigger world problem that should have been handled with a save, rollback or shard check instead.
Control world time and weather on purpose, and on the correct shard
World control commands are useful when season progression or weather gets stuck, or when you need to move the server state forward after maintenance. They change the simulation state, so the result is global for that world, not just one player’s view.
| Command | What it does | When to use it | Notes |
|---|---|---|---|
c_skip(n) | Skips n days; one day is 480 seconds | Advancing the world after a maintenance decision, or stepping out of a bad short-term state | This advances world time. It is not a lag fix; it moves the simulation on |
TheWorld:PushEvent("ms_setseason", "winter") | Sets the current season | Correcting a season state problem | Run on Master. Seasons are owned by Master and pushed to secondary shards |
TheWorld:PushEvent("ms_forceprecipitation", true)TheWorld:PushEvent("ms_forceprecipitation", false) | Starts or stops rain or snow | Correcting a weather state problem | Use as a world-state fix, not as routine weather control |
TheWorld:PushEvent("ms_setseason", "winter") If a season command “worked” in caves but the server still looks wrong, you probably ran it on the wrong shard. Send it to Master and let the season owner push the state out properly.
Clean up lag, check shard links, and diagnose commands that seem to do nothing
Clean-up commands that actually reduce world overhead
When a DST world gets messy, the real cost is not just visual clutter. Large numbers of entities mean more world state for the server to simulate on the main thread, more data to save to disk, and more object state for clients to receive. That is why blanket clean-up can help after uncontrolled item build-up. Save first, count second, remove third.
| Command | What it does | When to use it | Notes |
|---|---|---|---|
c_countprefabs("prefab") | Counts a prefab in the current shard | Checking if one item type has piled up enough to matter | Prints There are N prefabs in the world. |
c_removeall("prefab") | Deletes every instance of that prefab in the current shard | Removing runaway clutter after confirming the target | Irreversible. Prints removed N. Save or back up first |
c_find("prefab")c_gonext("prefab") | Finds the nearest one, or takes you to the next one of that prefab | Finding the exact offender before mass removal | Useful when players report “something somewhere is causing lag” |
c_debugshards()c_reregisterportals() | Shows connected shards and known portals; re-points cave portals to the connected shard | When caves seem disconnected or portal travel looks broken | Good first check before assuming save corruption |
c_netstats()c_repeatlastcommand() | Shows network statistics; repeats the last command | Separating network complaints from world-sim complaints; repeating a safe diagnostic command | Be careful with c_repeatlastcommand() after destructive commands |
When a command ran but nothing changed
Start with the simple failure points first. This flow helps you eliminate them in the right order.
| Symptom | Likely cause | Fix |
|---|---|---|
No Remote: prefix at all | You are not an admin on that server | Check adminlist.txt for the correct KU_XXXXXXXX, restart the server, then reconnect |
| Command echoed, but the world did not change | You typed it in Local: | Open the console, press Ctrl to switch to Remote:, then run it again |
| Season or weather command had no useful effect | You sent it to Caves instead of Master | Run the season or precipitation event on Master |
| Player command affected the wrong person | From a dedicated terminal, it hit AllPlayers[1] | Use c_listallplayers() and pass AllPlayers[n] or the KU ID explicitly |
| Spawn, move or gather command did nothing | The command needed a cursor and you used a server terminal | Run it in game through Remote: |
| Rollback did not undo the damage | c_rollback(1) only went back to the start of the current day | Use c_rollback(2) or a higher count to step back further days |
| Console throws syntax errors | Lua syntax mistake | Strings need quotes "", function calls need brackets (), and commands are case-sensitive |
Choose hosting and control tools that make admin work easy
If you rent a dedicated server, the panel matters almost as much as the hardware. The useful setup is simple: a separate console for each shard, easy access to the cluster folder so you can edit adminlist.txt, whitelist.txt and blocklist.txt, clear restart controls, and log access when you need to confirm what ran where. If caves are part of your normal world, separate Master and Caves consoles stop a lot of confusion.
Client-hosted worlds are fine for small private sessions, but dedicated hosting is easier once moderation, safe shutdown and caves become routine jobs. If you are comparing control panels and file access rather than just raw plan labels, our Don’t Starve Together server hosting comparison is the sensible place to start.
Look for per-shard console access, file management for the cluster folder, and restart controls that do not hide what happened on Master versus Caves. Those basics save more time than any gimmick once you are the person fixing a live world.
Compare Don’t Starve Together server hostsDon’t Starve Together server FAQ
How do I become admin on my Don’t Starve Together server?
Add your Klei user ID in KU_XXXXXXXX format to adminlist.txt, one ID per line, in the cluster folder with cluster.ini. Restart the server after editing the file. If you host a client-hosted world from the game, you are admin automatically.
Is there an admin password in Don’t Starve Together?
No. Don’t Starve Together does not use an admin password system for server access. Admin rights come from adminlist.txt and KU IDs, not from a chat command or a password field.
How do I roll back a Don’t Starve Together server?
Use c_rollback(count) from the correct server context, or /rollback [numsaves] if you want the built-in admin or vote route. The world saves at the end of each in-game day, so c_rollback(1) returns to the start of the current day and c_rollback(2) goes one day further back. By default the server keeps six snapshots.
Why do my DST console commands not work on the server?
The common causes are being in Local: instead of Remote:, sending the command to the wrong shard, or targeting the wrong player from a dedicated terminal. Check the prefix first, then check whether you are on Master or Caves, then verify the player with c_listallplayers(). Syntax matters too: quotes for strings, brackets for function calls, and correct case.
How do I kick or ban someone in Don’t Starve Together?
You can use the built-in chat and scoreboard tools, or the console. For console moderation, use TheNet:Kick("KU_xxxx"), TheNet:Ban("KU_xxxx"), or TheNet:BanForTime("KU_xxxx", seconds). Use the KU ID rather than guessing from the display name, and remember that vote-kick is temporary while a direct ban writes to blocklist.txt.
More Don’t Starve Together server help
Look after the world behind these commands, or compare hosts with per-shard consoles and full file access.
Commands, defaults and messages come from the Don’t Starve Together game scripts and Klei’s dedicated server settings guide as of November 2026. Host panels name their per-shard consoles and file managers differently, but the rules stay the same: Remote mode, the right shard, and the right player.
