Bannerlord cheats: enabling cheat mode and using the console on PC
Bannerlord has a way out of most soft-lock situations, and it ships in the box. The PC build of Mount and Blade II: Bannerlord includes a developer-style debug layer that the studio, TaleWorlds Entertainment, exposes through a configuration flag, an in-game debug UI, and a console command surface. None of this is a third-party hack: the same engine_config.txt that controls graphics quality also holds the cheat_mode entry that opens the door. The trade-off is that flipping that flag changes how the engine treats your save. Achievement tracking is the most visible consequence, and a save that was loaded with the flag set will not earn achievements even after the flag is reverted.
The word “cheats” in Bannerlord covers at least three different systems, and players regularly conflate them. There is the configuration flag itself, the keyboard shortcuts that fire effects during combat, and the typed console command language that mutates campaign and mission state. The flag enables the UI surface, the keybinds operate on the live battle, and the console reaches into save data. Treating them as one bucket is how saves get broken, because the UI layer and the console layer write to different parts of the engine state machine. The reference for everything below is the IGN wiki page that catalogs the cheats and console commands for the PC build, which is the only verified source used here.
What “cheats” means in Bannerlord
Layer one is the configuration flag. Layer two is the in-game inventory and party behavior unlocked by that flag, which is what most players mean by “I want to cheat in Bannerlord.” Layer three is the console command surface, which behaves more like a scripting interface than a cheat menu. A fourth category, third-party mods, technically exists on the same engine but is a separate ecosystem and is outside the scope of this guide.
The three layers at a glance
| Layer | Where it lives | What it changes | Save impact |
|---|---|---|---|
| Config flag (cheat_mode) | engine_config.txt in the Configs folder | Unlocks the inventory and party debug UI | Disables achievements on that save |
| Combat keybinds | Bound at runtime after the flag is set | Fires effects like damage, healing, and teleport during battles | Active in battles; effects persist for the encounter |
| Console commands | Console overlay opened with Alt + ~ | Runs campaign.* and mission.* scripted commands on live state | Directly mutates save state; risky if used mid-event |
For a developer or technical player, the most interesting layer is the console, because it is the closest thing Bannerlord ships to an internal scripting API. For a player who just wants to recover a lost battle, the inventory and party layer is usually enough. For modders, the same flag is the prerequisite for many of the scripting tools the community builds on top of the engine.
Enabling Bannerlord cheats through engine_config
The first gate is a single text file. Bannerlord’s engine reads a list of configuration keys at startup, and one of those keys tells the runtime whether to expose the debug UI. The verified walkthrough describes the path: the Documents folder, then Mount and Blade II Bannerlord, then the Configs folder, then the engine_config file. The flag in question is called cheat_mode, and its default value is 0. Changing that 0 to a 1 enables the cheats layer. The change is reversible by switching the value back, which is the official way to restore achievement compatibility on a new character.
Step-by-step setup on Windows
- Close Bannerlord completely if it is running. The engine writes its configuration back to the file on exit, so editing the file while the game is open risks the change being overwritten.
- Open File Explorer and navigate to
Documents\Mount and Blade II Bannerlord\Configs. The path is created the first time the game launches, so on a fresh install the folder may not exist until at least one run has completed. - Open
engine_config.txtin a plain text editor. Notepad is fine; Word and rich-text editors can save the file in a format the engine does not parse correctly. - Search for the line
cheat_mode = 0. The verified walkthrough recommends Ctrl+F to find the entry, since the file contains many other configuration keys. - Change the value to
cheat_mode = 1and save the file. The encoding should remain plain UTF-8 or whatever the original file uses; introducing a BOM or switching to a rich-text format can prevent the engine from reading the value at all. - Re-launch Bannerlord. The cheats layer is loaded at startup, so changes to the file after the game is running are ignored until the next launch.
The reversal is the same procedure in reverse: open the file, change the 1 back to a 0, save, and relaunch. The verified guide notes that Bannerlord attaches the achievement-eligible state to the save file, so toggling the flag back does not retroactively unlock achievements that were already disabled by a prior session. Players who want to keep a clean save for achievements are advised to maintain a separate character with the flag set, rather than toggling the same save back and forth.
File hygiene and common pitfalls
A surprising number of “my cheats do not work” reports come down to file-format issues rather than missing features. Three pitfalls appear repeatedly in community troubleshooting:
- Saving the file in a rich-text or UTF-16 encoding, which the engine parser rejects silently and falls back to default values.
- Editing a copy of the file in a different folder, such as the Steam install directory, instead of the user-specific Documents path.
- Forgetting that the file is rewritten on game exit, so a hand edit made after the game closed is preserved, but a hand edit made while the game was open is overwritten on shutdown.
For a developer mindset, the most useful detail here is the read-once-at-startup pattern. The engine treats configuration as a snapshot rather than a live setting, which is a common architectural choice for PC games that want predictable boot behavior. That same pattern explains why most of the other Bannerlord cheats require a restart to take effect.
What the cheat mode actually unlocks in-game
Once the flag is set and the game has been restarted, the debug layer changes two specific user interfaces. The verified source focuses on the Inventory screen and the Party screen, because those are the two surfaces where the flag has visible consequences for a typical player.
The Inventory screen
The Inventory screen becomes a flat catalog of every item the engine knows about. The left side of the window lists items in a developer-style table rather than the curated shop inventory a player normally sees, and clicking an item adds it directly to the character’s inventory. This is the fastest way to test how a late-game weapon or armor set behaves without grinding workshops, caravans, and trade orders. It is also the only place where the entire item catalog is exposed to the player, so it functions as a research tool for modders who want to know what item templates exist before they start writing XML overrides.
The Party screen
The Party screen exposes a similar flat list for troops. The verified guide explains that the player can pick any unit type from a list and add them directly to the party. This is useful for testing army composition, balancing siege assaults, or quickly checking the unit card of a faction the player has not yet allied with. For a developer, the troop list functions as a contract surface: every culture, every tier, and every upgrade path is visible without having to capture, recruit, or hire through the normal economy.
| UI surface | What the cheat flag exposes | Typical use |
|---|---|---|
| Inventory | Full item catalog, click to add | Test equipment, fill a treasury, outfit a custom lord |
| Party | Full troop catalog, click to add | Test unit balance, fill a garrison, build a custom army |
| Console (covered later) | Scripted campaign and mission commands | Modify state, fire events, scale difficulty, test encounters |
The flag does not, on its own, give the player gold, skill points, or renown. Those resources remain governed by the campaign state machine and have to be moved through the console layer or through a deliberate game-design path such as a tournament, a caravan run, or a completed quest chain. The distinction matters because the inventory and party surfaces are essentially read-and-spawn interfaces, while the console is a write interface against the campaign state.
Combat cheats: the keyboard-bound shortcuts
The third layer is the combat keybinds. The verified guide describes these as sequences of specific keys pressed in a specific order during a battle. The list is not part of the on-screen UI; the player has to know the key sequence, which is part of the reason the documentation pages for these cheats look like cheat sheets rather than tutorials. The effects include damage, healing, troop teleportation, and other combat modifiers that would otherwise require scripted encounters or specific perks.
How combat cheats fit into the engine
Combat in Bannerlord is driven by a mission state machine that runs on top of the campaign layer. The keybinds send direct events to that state machine, so they tend to be effective immediately rather than waiting for the next tick. For a developer, this is a useful illustration of how the engine exposes developer handles: rather than adding a separate combat debug menu, the developer layer borrows the same input pipeline that the player uses for tactical orders and routes the events to a different handler.
Working safely with combat cheats
- Trigger the cheats during a paused or pre-engagement state when possible, because some effects depend on the current target selection.
- Avoid chaining multiple cheats in the same frame, since the engine may drop or reorder events that arrive faster than the mission state can resolve them.
- Keep an autosave before the battle, because some combat cheats can push the mission into a state that the engine does not gracefully recover from if the player exits to the campaign map mid-effect.
Combat cheats are the most fragile of the three layers because they touch live mission state. The inventory and party cheats mutate campaign state in ways the engine is designed to handle, but combat cheats can produce edge cases that the team has not tested against every unit, formation, and terrain combination. A defensive workflow is to keep a recent save, treat the cheats as a test harness rather than a permanent buff, and disable the flag again before resuming a serious campaign.
The console command surface
The console is the deepest layer and the one with the most developer relevance. The verified guide describes it as a window on the left side of the screen, opened with Alt plus the tilde key or the backtick on the far left of the keyboard, just above Tab. Once open, the player types commands directly into a text field at the bottom of the window. The engine responds by executing the command against the current campaign or mission state, and the result shows up in the campaign or the active battle.
Command naming convention
Bannerlord’s PC build ships with a hidden developer layer that has been part of the franchise since the earlier Mount and Blade titles. The layer is gated behind a single boolean flag in a text configuration file, and once that flag is set, three separate systems become available. The verified reference for this surface is the IGN wiki entry on Mount and Blade II cheats and console commands, which documents the file path, the flag, and the consequences on inventory, party, and combat state.
Console commands are organized under prefixes that mirror the engine’s internal namespaces. The verified guide calls out two prefixes in particular: campaign. and mission.. The campaign prefix reaches into the persistent state of the player’s save, which means the effect survives a save and load. The mission prefix reaches into the live battle state, which is reset every time the player enters or exits a battle. Other prefixes the engine recognizes include the user-interface toggle ui.toggle_ui referenced in the verified guide, which switches individual UI panels on or off.
A worked example: adding gold
The verified guide walks through a specific example. The command campaign.add_gold_to_hero adds a fixed amount of gold to the player’s treasury each time it is run. The default behavior described in the source is 1,000 denars per invocation. Because the command is a campaign-state mutation, the result is saved with the rest of the player’s treasury, so it is a permanent change unless the player actively removes the gold through a trade or a settlement fee.
A worked example: adding attribute points
The attribute-point command illustrates a different shape. The verified guide notes that campaign.add_attribute_points_to_hero only adds one point by default, but accepts a numeric argument that scales the result. Typing the command followed by 10 adds ten points, and following it with 50 adds fifty. The argument-passing model here is a string-suffix style rather than a structured parameter parser, which is consistent with the rest of the engine’s input handling.
| Command family | Example | Effect | Argument behavior |
|---|---|---|---|
| campaign.add_gold_to_hero | Adds denars to the player treasury | Persistent, survives save and load | Default 1,000 per use |
| campaign.add_attribute_points_to_hero | Adds unspent attribute points to the hero | Persistent, applies at next level-up screen | Numeric suffix scales the result |
| ui.toggle_ui | Toggles a UI panel on or off | Visual, no state change | No argument needed in the verified examples |
| campaign.* (broader family) | Scrolling list of campaign state commands | Reaches into campaign state for many subsystems | Each command defines its own argument shape |
| mission.* (broader family) | Scrolling list of mission state commands | Active only in the current battle | Each command defines its own argument shape |
The practical advice is to treat the console as a read-the-list-first surface. The verified guide describes scrolling through the available options, and the engine exposes a relatively flat list of command names rather than a structured help system. New commands do appear with patches, and some commands are removed or renamed as the underlying state machine evolves, so the most defensive workflow is to look up the current command list rather than memorizing commands from older patches.
Disabling cheats and protecting achievement-eligible saves
Disabling the cheats layer is a mirror of enabling it. The verified guide describes the same file, the same flag, and the same edit, with the only difference being that the value goes from 1 back to 0. After saving the file and relaunching, the inventory and party debug behavior disappears, and the console stops responding to the toggle key combination. The player’s existing save files remain on disk; only the runtime interpretation of those files changes.
The catch, called out explicitly in the verified guide, is that achievements are tied to the save file’s cheat state. A save created with the flag set to 1 will not earn achievements, even after the flag is set back to 0. The clean way to keep achievements alive is to maintain a separate character whose config flag has never been touched, and to use a different character for any testing that requires the debug layer. Bannerlord supports multiple save files and multiple active characters on the same install, so the separation is a workflow choice rather than a hard limit.
Recommended save discipline
- Keep at least one clean character with the config flag at 0 for achievement runs and serious campaigns.
- Use a separate test character with the flag at 1 for console experiments, inventory stress tests, and combat cheat exploration.
- Avoid running the same save under both flag states, since the engine’s interpretation of the save header can be inconsistent across sessions.
- Back up the Documents folder before major patches, since engine updates sometimes reset or migrate configuration files.
For developers and modders, the back-up habit has a second benefit: many modding tools assume a specific engine version and a specific configuration state, and a clean rollback path makes it easier to bisect whether a strange behavior is coming from the mod, the engine update, or the cheat flag.
Where the official cheats end and third-party tools begin
Bannerlord’s modding ecosystem sits on top of the same engine and shares many of the same code paths, but it is not part of the verified cheats layer. The official tools that ship with the game include the configuration flag, the inventory and party debug UI, the combat keybinds, and the console command set. The modding scene adds XML overrides, Harmony patches, custom modules, and external trainers that inject directly into the running process. The two ecosystems overlap at the console layer, because some community tools are thin wrappers around the same campaign. and mission. commands.
For a developer or technical player, the meaningful distinction is trust boundary. The official cheats run inside the engine’s own command pipeline and have to respect the campaign state machine. Third-party tools run in the same process but use a different injection method, so they can read or write memory addresses the engine itself never exposes. That extra reach comes with extra risk: anti-cheat layers in some games treat process injection as a ban-worthy signal, and even when no anti-cheat is involved, a poorly written trainer can corrupt a save in ways the engine has no recovery path for. Bannerlord on PC has no kernel-level anti-cheat for the single-player campaign, but the same caution applies in principle.
When to use which
- Use the official cheats when the goal is to recover from a soft failure, test a build, or experiment with a feature in a controlled way.
- Use console commands when the goal is to mutate a specific piece of campaign or mission state and observe the engine’s response.
- Use third-party tools when the goal is to automate, to reach state the official surface does not expose, or to integrate with a broader modding pipeline.
- Avoid mixing third-party tools with achievement-eligible saves, since the resulting save is no longer in a state the engine can vouch for.
The verified source only documents the official surface, so anything beyond the inventory, party, combat, and console layers is editorial context. Where a fact is not in the verified reference, this guide either omits it or flags it as a general observation rather than a sourced claim.
Risks, edge cases, and what the verified source does not promise
The verified guide describes the cheats layer in optimistic terms, and that framing is appropriate for a player who wants to recover a lost battle or speed up a second playthrough. It is less appropriate for a developer who needs to reason about save integrity, version compatibility, or engine state. A few risks are worth calling out explicitly.
Save corruption
Console commands write directly to campaign state. If a command is fired during a quest event, a battle resolution, or a settlement interaction, the engine may complete the event with a half-modified state and write the result to the save file. Most of the time the result is recoverable, but the verified source does not promise that every command is safe at every moment. A defensive habit is to save manually, run the command, reload, and verify the result is what was intended before continuing.
Version drift
Bannerlord has received multiple major patches since launch, and each patch has the potential to rename, remove, or rebalance the same console commands. The verified guide describes the surface as it stood at the time the page was written, and the engine has evolved since. Any specific command name or argument shape should be cross-checked against the in-game console list before relying on it for a workflow that has to survive a patch.
Compatibility with mods
Mods that alter campaign or mission state can interfere with the official cheats in unpredictable ways. A mod that adds a new resource, a new troop type, or a new quest can change the data the console commands expect, and the engine’s response to a command that targets a missing object is not always graceful. The safest workflow is to disable mods, verify the official cheats work as documented, and then re-enable mods one at a time to find the conflict.
| Risk | What triggers it | Defensive habit |
|---|---|---|
| Save corruption | Console command fired during a live event | Manual save before the command, reload to verify |
| Version drift | Engine patch renames or removes a command | Cross-check command names against the in-game list |
| Mod conflict | Mod alters the data shape the command targets | Test with mods disabled, re-enable one at a time |
| Achievement loss | Flag toggled on, even briefly, on the same save | Use a separate character for cheat-flag sessions |
None of these risks are unique to Bannerlord, and none of them are reasons to avoid the official cheats entirely. They are reasons to use the layer the way a developer uses a debug build: deliberately, with a clean baseline, and with a rollback path.
Frequently asked questions
Are Bannerlord cheats available on console?
The configuration file, the in-game debug UI, and the console command surface are PC features. Console versions of Bannerlord do not expose the same flag, and the verified source documents the path through the Windows Documents folder. Players on console versions are limited to in-game mechanics, exploits that the engine has not patched, and any save manipulation that the platform’s own tooling supports.
Do Bannerlord cheats disable achievements permanently?
For the save file that was loaded with the flag set to 1, yes. The verified guide explicitly recommends keeping a separate character for the cheat-flag workflow. A different character whose config has never been set to 1 can still earn achievements on the same install.
Can I use the console commands without enabling the cheat mode flag?
The verified source ties the console overlay and the inventory and party debug UI to the same flag, so the documented workflow requires the flag to be set to 1 first. Without the flag, the console is not exposed through the Alt + tilde binding the source describes. A handful of community tools open the same engine pipeline through a different injection point, but those are outside the official surface.
Will using cheats corrupt my save file?
Most invocations are safe, but the verified source does not promise that every command is safe at every moment. The most defensive habit is to save manually before firing a command, then reload and verify the result. Console commands that target mission state are riskier than commands that target inventory state, because mission state has more transient objects and unresolved handlers.
Where is the engine_config.txt file located?
On Windows, the file lives at Documents\Mount and Blade II Bannerlord\Configs\engine_config.txt. The folder is created the first time the game launches, so a fresh install needs at least one run to complete before the file exists.
What is the difference between combat cheats and console commands?
Combat cheats are key sequences that fire effects during a battle, while console commands are typed inputs that mutate campaign or mission state. The combat cheats are more limited but faster to use, and the console commands are more flexible but require the player to know the command name and the argument shape.
Can console commands add any amount of gold?
The verified guide describes campaign.add_gold_to_hero as adding a fixed amount per invocation, with the example value of 1,000 denars. Whether the command accepts a numeric argument that scales the result is not specified for gold in the verified excerpt, and the engine’s behavior with a custom argument should be tested on a sacrificial save before relying on it for a serious campaign.
Do I need to disable mods before using cheats?
It depends on the mod. Mods that change campaign data, troop definitions, or quest state can interfere with the official commands in unpredictable ways. The safest workflow is to disable mods, verify the cheats work as documented, and then re-enable mods one at a time until a conflict shows up.
Are the cheat commands updated with every patch?
The engine surface evolves with each patch, and command names, argument shapes, and effect sizes can change. The verified source describes the surface as it stood at the time of writing, so any command used in a long-running workflow should be re-checked against the in-game console list after a major update.
Is using Bannerlord cheats allowed by TaleWorlds?
The flag ships with the game, the inventory and party UI is part of the same surface, and the console is part of the same engine. The verified source treats the workflow as a documented part of the PC build rather than an exploit. Players who care about competitive leaderboards or achievement integrity should still treat the cheats as a separate workflow with its own character and save files.








Leave a Reply