Quick answer: Reference the .inputactions asset via a serialized field, Resources folder, or Addressable. Unity only includes referenced assets in builds.

A puzzle game uses Input System with a Controls.inputactions file. Loads fine in editor; built game logs NullReferenceException at first input read. Asset wasn’t in the build.

Why It Works in Editor

Editor uses AssetDatabase; can load any asset by GUID instantly. Build only ships assets in the build set. Unreferenced files are excluded to keep build size lean.

Fix 1: Serialized Field

using UnityEngine.InputSystem;

public class InputController : MonoBehaviour
{
    [SerializeField] private InputActionAsset actions;

    void OnEnable() { actions.Enable(); }
}

Drag the .inputactions into the field in inspector. Builds include the referenced asset.

Fix 2: Generated C# Class

Right-click .inputactions in Project → Generate C# Class. Tick “Generate Class” in the asset’s Inspector. Then:

private Controls _controls;

void Awake() {
    _controls = new Controls();
    _controls.Enable();
}

Class instance creates the action map at runtime — no asset reference needed. Compiles into your assembly.

Fix 3: Resources Folder

// Assets/Resources/Controls.inputactions
var actions = Resources.Load<InputActionAsset>("Controls");
actions.Enable();

Anything in Resources/ always ships. Use sparingly — Resources are loaded into memory at startup.

Verify Inclusion

Build Report (Library/LastBuild.buildreport):

Verifying

Build for target platform. Run; input responds. No null refs at startup. Profile memory; input asset weight is negligible.

“Unity builds only reachable assets. Reference your inputactions or generate the C# class to make it bulletproof.”

Generated C# classes are the cleanest: no inspector wiring, no Resources cost, fully refactor-safe. Use them.