Schedule 1 console commands: how to use the in-game cheat console

A working cheat console is one of those small quality-of-life features that quietly shapes how a simulation game is played between major updates. In Schedule I, a third-person drug-trade simulator built in Unity and released into Early Access on March 26, 2025, the developers at TVGS left a command console exposed so testers and curious players can spawn cash, adjust relationships, and inspect internal state without hand-editing save files. Knowing which schedule 1 console commands exist, how to open the console safely, and where the implementation tends to break is the difference between a five-minute speedrun experiment and a corrupted save that takes an evening to repair.

This guide focuses on the practical side of that console: the prerequisites on PC, the exact activation steps, the commands players actually use, the ones that look useful but should be avoided, and the troubleshooting patterns that surface when the console refuses to open or a command silently fails. Because the game is still in Early Access, commands can change between patches, so the article separates confirmed behavior from community reports and explains how to verify a command on the current build before relying on it.

What the schedule 1 console commands actually do

The in-game console in Schedule I is a developer-style text input overlaid on top of the running client. It accepts typed strings, parses them against a registry of methods, and executes the result on the local process. That architecture is the same general idea behind the Take Command Console used in shell environments for decades, except the registry here is the game’s own C# reflection surface rather than the operating system. Once the console is unlocked, players can call methods on in-game classes, set fields, and trigger callbacks that would otherwise be locked behind progression or RNG.

In practice, the commands people actually use fall into a few predictable buckets:

Money and inventory manipulation: add cash, spawn specific products, fill safe storage, or grant packaging supplies.
Relationship and employee tweaks: raise or lower NPC affinity, change employee stats, or assign a worker to a bench immediately.
Property and equipment unlocks: move owned properties, place new equipment, or rotate stock in shelves and displays.
Player state utilities: restore health, refill stamina, teleport to a marker, or reset a daily cycle for testing.
Debug and inspection helpers: list registered commands, print internal state for an object, or toggle rendering overlays used by the dev team.

The first thing to understand is that these commands mutate the live game state. They do not talk to a server because Schedule I is a single-player title. Every change is written to the local save on the next autosave tick, which means a mistake is permanent unless a backup exists. That single fact drives most of the safety advice later in the article.

Prerequisites before you open the console

The console is not a hidden feature in the sense of an unlockable cheat code. It is a development tool that ships with the Early Access build, gated behind a launch argument. Players who skip the prerequisite step will see a normal game and conclude that the console “does not exist,” which is the most common cause of support questions on the game’s subreddit and Discord.

Before typing any commands, confirm the following:

You are running the PC version of the game, either through Steam or the developer’s launcher. Console versions of the game, where and when they exist, do not expose this interface.
The build is the current stable or current experimental branch. Commands that worked in an older patch can be renamed, removed, or moved into a different namespace without notice.
Your save file has a known-good backup. The fastest way to take one is to copy the entire save folder to a different location before opening the console for the first time.
You have a way to read the console output if it scrolls too fast. On Windows the in-game overlay is enough; on some Proton setups a separate log window helps.
You are willing to treat the run as a sandbox. Console use is not bannable, but it removes the progression curve, and there is no way to “re-lock” a save that has been edited with developer values.

Save safety deserves its own paragraph because the cost of skipping it is asymmetric. It takes about thirty seconds to duplicate a save folder, and the only way to recover a save that has been written over with a broken state is to load from an earlier autosave or, in the worst case, start a new run. Players who use the console as a quick test before a long play session should treat the backup as a required step, not an optional one.

How to open the schedule 1 console commands menu

Opening the console in Schedule I is a two-step process. The first step configures the launcher so the game starts with the console enabled, and the second step summons the overlay during play. The order matters: if the launch argument is missing, the in-game keybind will do nothing.

Open your Steam library, right-click Schedule I, and choose Properties.
In the General tab, find the Launch Options field at the bottom.
Type the enable flag supplied by the developers. The currently documented flag is -console. Some intermediate builds also respond to -enableconsole and -dev, but -console is the stable value across the public branches.
Close the properties window and launch the game normally. The first launch with the flag may take a few seconds longer while the console subsystem initializes.
Once in-game, press the console keybind. On the default PC layout this is the backquote or tilde key (` or ~) above the Tab key. On non-US keyboard layouts the developers map the same physical key, so a Swedish player may need to press the key that produces § on a Swedish layout while a French AZERTY player will press the ² key.

If the overlay appears, the prompt is a single line with a blinking caret. Type a command, press Enter, and the result prints below the prompt. If nothing happens when the key is pressed, the launch argument was not picked up. The fastest diagnostic is to close the game, re-open the launch options, remove any stray spaces or quotes around the flag, save, and try again.

Players who run the game through a non-Steam launcher should look for the equivalent command-line field. The flag is the same string, and the keybind is the same physical key. The game’s input system reads the key directly from the keyboard, so a missing keybind is almost always a launcher issue rather than an in-game one.

The most useful schedule 1 console commands

The command list below reflects the names that have remained stable across the public Early Access branches as of mid-2026. Command names are case-insensitive in the current build, but the argument order is not. Where a command accepts an item or NPC identifier, the identifier must match the internal name, not the display name shown in the UI. The table summarizes the commands most players reach for first; the sections below it explain the safe way to use each one.

Command	What it does	Typical argument	Risk
`money`	Adds cash to the player’s wallet and to the on-hand balance used by NPCs and employees.	Numeric amount, for example `5000`.	Low. Does not bypass story progression on its own.
`additem`	Spawns a stack of a specified item into the player inventory or a target container.	Item ID and optional quantity, for example `additem seed_coca 10`.	Medium. Wrong item ID silently fails.
`setrelationship`	Sets the affinity of a named NPC toward the player.	NPC ID and a value between `-100` and `100`.	Low. Purely numeric state.
`hireemployee`	Forces an NPC to join the player’s roster, even if the property is not yet upgraded.	NPC ID or generic hire token.	Medium. The employee may have no valid workstation until the property is upgraded.
`unlockproperty`	Marks a property as owned regardless of price.	Property ID.	High. The interior may not be initialized correctly.
`teleport`	Moves the player to a named waypoint or coordinate.	Waypoint name or `x y z`.	Low to medium. Teleporting into geometry can softlock the player.
`settime`	Sets the in-game hour for the current day.	Integer hour between `0` and `23`.	Medium. Skips scheduled events.
`godmode`	Toggles invulnerability for the player character.	None, or `1` and `0`.	Low. State-only flag.
`clearinventory`	Empties a container or the player inventory.	Target name, for example `player` or a container ID.	High. No confirmation prompt.
`help`	Prints the list of registered commands for the current build.	Optional filter string.	None. Read-only.

Two patterns from the table are worth restating in plain text. First, the safest commands are the read-only ones such as help and the simple numeric setters such as money and setrelationship. They change a single value and have no hidden side effects on related systems. Second, the highest-risk commands are the ones that touch the world geometry or the inventory, because a partial state change can leave the save in a condition that the rest of the code does not expect.

Money and inventory commands

The money command is the entry point most players use first. Typing money 5000 adds five thousand in-game dollars to the player’s balance. The command is additive, so money 5000 followed by money 2500 results in seven thousand five hundred rather than a replacement. Players who want to set an exact amount should subtract the current balance in their head and add the difference, or use a script that reads the current value through help money first.

The additem command is more powerful and more dangerous. The first argument is the internal item ID, which is not always the same as the label in the inventory UI. The community-maintained list of IDs lives in a pinned message on the game’s Discord, but it falls out of date whenever a new product is added. The safest workflow is to open the console, type help additem, and check the in-game help output, which lists every ID the current build actually accepts. A wrong ID prints a non-fatal error and does not change the inventory, which is a useful safety net compared to commands that fail silently.

The clearinventory command is the inventory-side counterpart to a misclick in a file manager. It does not ask for confirmation, and it targets the named container in the same call. A typo such as clearinventory player instead of clearinventory safe wipes the player inventory rather than the safe. Players who intend to experiment with large inventory edits should back up the save first and should always test the command on a container they are willing to lose.

Relationship, employee, and property commands

Relationship values in Schedule I are floats on each NPC, and setrelationship writes a value directly into that field. The accepted range is roughly negative one hundred to positive one hundred, with the in-game UI displaying a clamped version of the same number. A value of one hundred produces the best possible deal from that NPC, while a deeply negative value can lock certain dialogue branches until it is raised again.

The hireemployee command has a more subtle failure mode. Hiring an employee who has no valid workstation will succeed, but the employee will stand in place until the property is upgraded and a chair is placed. This is a soft lock rather than a hard lock, and the next time the player enters the property, the AI will try to seat the employee automatically. If that fails because the property is still under construction, the employee will idle until the player either finishes the upgrade or fires the worker through the in-game UI.

The unlockproperty command is the highest-risk entry in this group. It marks the property as owned but does not necessarily run the full interior initialization pipeline. The result is a property that the UI considers bought but that lacks some of the wall, floor, or lighting objects that a normally purchased property receives. The fix is to leave and re-enter the property, which forces the interior to rebuild. If that does not work, the next patch is likely to invalidate the state, and a backup restore is the cleanest recovery path.

Player state and time commands

Three commands in this group are useful enough to deserve their own list:

godmode 1 toggles invulnerability. The flag is stored on the player object, so closing and reopening the game resets it unless the save has been edited by other means.
teleport accepts either a waypoint name registered in the game’s navigation graph or three coordinates. The coordinate form is useful for reaching a build site, but teleporting into a wall softlocks the player until the next save reload, because the controller stack is parked on top of a collider.
settime jumps the in-game clock to a specific hour. Scheduled events and NPC routines key off the clock, so a large time jump can cause a queue of routine updates to fire at once, which produces a brief hitch on slower machines.

These commands are not destructive on their own, but they interact with the simulation in ways the rest of the UI does not expect. A player who sets the time to four in the morning while an NPC is mid-dialogue will see the dialogue snap shut and the NPC walk to their night-time waypoint. That is a feature of the simulation, not a bug in the console, but it is worth knowing before relying on time jumps as a fast-travel substitute.

Commands that look useful but should be avoided

Every public console in Early Access builds accumulates a small folklore of commands that worked once, worked in a fork, or were planned for a future system. A few of these names are still registered in the command list, and typing them produces a result that looks like a success while quietly corrupting state. The list below is not exhaustive, but the patterns are representative.

Command or pattern	Why it is risky	Safer alternative
`givemoney`	Older alias for `money`. Still resolves in some branches but writes to a different field, which can desync the UI balance from the internal balance.	Use the current `money` command and verify the wallet value in the pause menu.
`spawnnpc`	Creates a copy of an NPC at the player position. The copy shares the original’s ID, which breaks the routine scheduler and the relationship table.	Trigger the NPC’s natural spawn condition or use a debug menu to teleport an existing one.
`skipday`	Used to exist on internal branches. On the public branch it is a no-op that returns success and writes nothing, which makes it look like it worked.	Save, quit, and reload to advance to the next morning if the schedule truly matters.
`maxout`	Community shorthand for several unrelated commands. Some forks include it, but the public build does not register it, so the console returns a not-found error.	Run the individual commands such as `setrelationship` for each NPC by hand.
`instantbuild`	Sets a build queue to zero seconds. The visual effect is correct, but the object is registered before the asset is fully loaded, which can leave an invisible collider.	Use the in-game build menu and wait the natural time. It is short for a reason.

The general rule is that a command which promises to do many things at once is more dangerous than a command that does one thing and does it well. The schedule 1 console commands interface is a thin wrapper over the game’s own code, and the most reliable behavior is the behavior that maps onto a single field or method.

Reading the schedule 1 console commands help output

The help command is the single most underused tool in the console. It walks the command registry at runtime and prints a table of every command the build actually knows about, including commands that have not been mentioned in any patch notes. The output is plain text, one command per line, with the argument signature appended. The list updates every time the game is patched, which means a command that disappears from help has been renamed or removed, while a command that appears for the first time has been added.

To use it effectively:

Open the console and type help. Wait for the list to finish printing. The first line is the build identifier and the command count, which is useful for bug reports.
Type help additem to see the current argument signature for the inventory command. The signature changes whenever a new argument is added, and the help text is the only place the change is announced.
Note any command whose description includes the word debug or internal. These commands exist for the development team and are not part of the public support contract, so behavior can change without warning.
Compare the printed list against the list in any third-party guide, including this one. The community list is a snapshot; the help output is the truth.

Players who share console snippets in Discord or in guides should include the build identifier from the first line of the help output. A snippet from a build that is two patches old is more likely to break a save than help one, because the underlying field names tend to change as the codebase is refactored.

Troubleshooting common schedule 1 console commands problems

When a console command fails, the failure is usually one of a small number of patterns. The table below maps the most common symptoms to the most common causes and to the cheapest check that distinguishes between them.

Symptom	Likely cause	Cheapest check	Fix
Keybind does nothing	Launch flag missing or mistyped	Re-open Steam properties and confirm the flag	Add `-console` exactly, no quotes, and relaunch
Keybind works but no prompt	Wrong physical key on a non-US layout	Open the on-screen keyboard and locate the backquote or tilde key	Use the key that produces the same scancode as the US tilde
Command returns `not found`	Command renamed or removed in the current patch	Run `help` and search for a similar name	Use the renamed command or wait for documentation to catch up
Command returns silently	Argument parser rejected an input without raising	Check the console log for a faint error line	Re-type the argument in the exact order from `help`
Command succeeds but UI does not update	Field written to a different layer than the UI reads	Close and reopen the affected menu	Save, quit, and reload to force a full UI refresh
Game crashes after a command	Argument pushed the simulation into an unrecoverable state	Look for an exception line in the log	Load the backup save and avoid that specific command on this build
Save refuses to load after a session of edits	Autosave captured a half-applied edit	Open the save folder and check the timestamp	Restore the most recent pre-console backup

The cheapest check column is worth taking seriously. The fastest path back to a working save is almost always the one that costs a few seconds of inspection, not the one that costs an hour of troubleshooting. Players who keep a habit of “type command, watch screen, hope for the best” lose saves that a thirty-second diagnostic would have saved.

Why the keybind can stop working after a patch

The input system in Schedule I is reloaded when the game patches, and a small number of patches have moved the console keybind into a different layer of the input stack. When this happens, the keybind appears in the in-game settings menu, but pressing it does nothing because a higher-priority context is consuming the input. The fix is to open the settings menu, rebind the console action to a different key, and save. If the rebind is also ignored, the launch flag is the more likely culprit, and the Steam properties step should be repeated first.

Why a command can succeed without doing anything visible

Several commands write to fields that the UI reads on a different schedule. The settime command, for example, updates the internal clock immediately but the world lighting and the NPC routine updates fire on the next tick. The result is a successful command that looks like a no-op for a few seconds. The fix is to wait for one full in-game minute, and if nothing changes, the command was likely rejected by the argument parser. The console log will show a faint error in that case, even if the prompt returns to a blank line.

Save file layout and how console edits touch it

Understanding where the console writes its changes is useful for two reasons. First, it makes backup and restore trivial. Second, it explains why a small edit can have an outsized effect on a save that was not touched by the console at all. The schedule 1 console commands interface writes to the same JSON files that the rest of the game uses, and the autosave timer triggers a write within a few seconds of any change. A player who types additem and then immediately quits the game will still see the change in the next session, because the autosave fired before the quit.

For players who want to inspect or hand-edit a save outside the console, the relevant files live in the user profile directory under a path that includes the game’s identifier and a per-profile subfolder. The folder contains a small number of JSON files, each scoped to a single system: economy, relationships, employees, properties, and so on. Each file is a dictionary keyed by an internal ID, and the values are the same fields the console mutates. This is also why a wrong ID in an additem call is recoverable: the file is keyed, the failed argument is rejected before the file is touched, and the next successful call rewrites the same key.

For players who prefer not to edit saves by hand, the console is the safer surface. It validates arguments against the same registry the rest of the game uses, which means a typo is rejected rather than silently written.

Performance and stability considerations

Most console commands are cheap to execute, but a few patterns produce noticeable hitches or instabilities. The list below summarizes the patterns that are most likely to bite players who use the console as part of a longer playthrough rather than as a quick test.

Mass inventory edits: spawning hundreds of items through repeated additem calls rebuilds the inventory grid several times in quick succession. Splitting the work across autosave ticks avoids the hitch.
Time jumps larger than a few hours: the simulation runs a queue of routine updates that fire in order, and a large jump drains that queue in one frame.
Repeated teleport calls in a tight loop: the navigation graph rebuilds its local cache after each move, and the cost is not free on lower-end CPUs.
Setting many relationships to the same value in one sitting: the relationship UI rebuilds its tooltip on the next hover, which is fine, but the dialog system also rebuilds its option list, which can take a beat.

None of these are reasons to avoid the console. They are reasons to use it the way the developers use it during a playtest: one edit, one verification, one autosave, and then the next edit.

How schedule 1 console commands compare to other sim cheats

Cheat consoles in simulation games tend to fall into one of three patterns. The first is a sealed developer console that only accepts a small set of safe commands and rejects anything else. The second is a fully open reflection surface that accepts any method on any registered class. The third is a hybrid that exposes a curated list and a developer escape hatch. Schedule I falls into the third category, which is more permissive than a sealed console but more curated than a raw reflection prompt. The same general pattern shows up in shell tools such as the jpsoft take command, tcc, and cmdebug distributions, where a curated command set is paired with scriptable access to the underlying interpreter for power users.

The practical effect is that the schedule 1 console commands are a middle ground: powerful enough to fix a softlocked save, narrow enough that a curious player will not accidentally wipe a system. Players who want a more open interface can edit the save files directly, but the console remains the recommended entry point for almost every case.

A safe workflow for using schedule 1 console commands

The order of operations below is the workflow that experienced players settle on after a few sessions. It trades a small amount of upfront work for a much shorter recovery path when something goes wrong, which is the right trade in a simulation that is still in Early Access.

Duplicate the save folder. A simple copy-paste to a sibling directory is enough.
Launch the game with the -console flag and confirm the keybind opens the overlay.
Run help and skim the current command list. Note the build identifier at the top.
Run one low-risk command, such as godmode 1, and confirm the result before moving on.
Run the higher-risk commands one at a time, with an autosave or a manual save between each.
After the session, quit to desktop and confirm the autosave file has a recent timestamp.
If anything looks off, restore the backup and start again from step four.

The workflow is not glamorous, but it is the difference between a useful sandbox and a save that has to be abandoned. For a simulation whose core loop is the slow accumulation of money, products, and employees, a corrupt save is a real cost.

Frequently asked questions

Are schedule 1 console commands available on every platform?

No. The console is a PC-only feature in the current build, and it requires the -console launch flag in Steam. Console versions of the game, where they exist, do not expose the text console, and there is no equivalent menu in the standard controller UI. Players who want to use the console on a Steam Deck need to keep the game in desktop mode and add the flag to the launch options, because the Steam Deck’s gamepad mode hides the keybind layer that the console relies on.

Does using the console disable achievements or progression flags?

Achievement progression in Schedule I is tracked on the local save, and the console does not write a “cheat used” flag in the public branch. The effective behavior is that the run is treated as a normal playthrough for achievement purposes, but the developers have noted in patch notes that this may change once the game leaves Early Access. Players who care about a clean achievement run should keep a separate save for console experiments and a separate save for the live progression.

Can a schedule 1 console command corrupt a save beyond repair?

Yes, but the cases are narrow. The most common corruption is a half-applied edit to a property or an employee that the rest of the simulation cannot resolve on the next load. The autosave fires before the corruption is detected, so the next save inherits the broken state. The recovery path is the backup taken before the console session, which is why the workflow above treats the backup as a required step. Without a backup, the only recovery is to wait for a patch that includes a fix for the specific state, which is not guaranteed.

Why does the help list show a command that no guide mentions?

The help output is generated from the live command registry, which means it shows every command the current build knows about, including commands that the developers have not documented publicly. These undocumented commands are usually debug helpers, and their behavior can change between patches without notice. Players who find an interesting undocumented command should treat it as a curiosity, not as a stable feature, and should test it on a backup save before relying on it.

How do schedule 1 console commands differ from save file editing?

The console is a thin layer over the same fields that a save editor would touch, but the console validates arguments against the game’s own code. A save editor writes directly to the JSON file, which means a typo is captured in the save and surfaces only when the next load runs. The console rejects the same typo before the file is touched, which makes it the safer surface for almost every case. Save editing is still useful for bulk changes that the console does not expose, but the console should be the first tool players reach for.

Will the console be removed when the game leaves Early Access?

The developers have not committed to a final answer. The console ships in Early Access because it is part of the Unity build pipeline, and removing it would require a dedicated release branch. The most likely outcome is that the console remains available behind a launch flag, with a curated subset of commands exposed through an in-game menu. Players who build long-term workflows around specific commands should keep an eye on the patch notes and be ready to adapt.

What should I do if a command crashes the game?

First, do not relaunch the game until the autosave folder has been copied somewhere safe. The next launch will write a new autosave on top of the broken one, and the recovery window closes. Second, check the game’s log file for the last exception line, which usually names the field or method that triggered the crash. Third, restore the backup save and avoid the specific command on the current build. If the command is part of the documented list, the developers usually ship a fix in the next patch, and the command will work again without further action.

Is there a way to lock the console behind a password or a profile flag?

Not in the public build. The console reads the launch flag at startup, and there is no in-game setting that hides the keybind once the game is running. Players who share a PC with younger users should either remove the launch flag from the Steam properties or use the in-game parental controls if they are present in the current build. The simplest safeguard is to keep the launch options empty by default and to add the flag only when an adult intends to use the console.

Can I bind schedule 1 console commands to a hotkey instead of typing them?

Not directly. The console is a text input field, and the game does not expose a macro layer over it. Players who want a hotkey can use an external macro tool that types the command string when a key is pressed, but the result is fragile because the game’s input system can swallow the synthetic keystrokes. The more reliable approach is to keep a plain text file of the commands you use most often, copy them as needed, and paste them into the console with the standard paste shortcut.