The game tells Companion when it saved changed key bindings

[Pelotrio]

Stacked on #122. Closes its known gap: a key rebound in the game while Companion is visible beside it but not focused now shows at once, not only after the user clicks into Companion.

Contract

• Mod: whenever any screen closes, the game compares its key bindings, encoded as options.txt saves them (KeyBindingEdits.assigned()), with those when a screen closed before. Where they differ, it queues KEY_ASSIGNMENTS with Minecraft.tell, so it is sent after the screen saved options.txt.
  • In NeoForge 1.21.1, Minecraft.setScreen posts ScreenEvent.Closing before old.removed(), and OptionsSubScreen.removed() is what saves options.txt.
  • Minecraft.execute would run the task at once on the client thread, before the save, so the mod uses tell.
• Companion: the message calls KeyBindingControl.saved(), which refreshes its FileReading of options.txt. options.txt stays the one place keys are read from. Merging, newest wins and closing are FileReading's contract from Files others write are read when shown and when the user comes back #122; nothing new is async here.
• The message carries nothing. Sending the assignments from memory would give Companion a second source to reconcile with the file. Since the game always saves before the message goes out, the file is enough.

Who reads the keys (inventory)

Consumer	Before	Now
Key bindings page (KeyBindingControl.assignments(), follows assignmentsChanged())	Read on show, on return to Companion, after Companion's change	Also after the game's message
KeyBindingLabels (follows assignmentsChanged())	Same	Same, plus the message
KeyBindingControl.set()	Refreshes after the game answered or Companion wrote	Unchanged; the game's own save there opens no screen, so no extra message
KeyBindingControl.readFile (pipeline conflict check)	Reads options.txt itself	Unchanged

Nothing is removed.

Edge cases

• With no Companion connected the message is dropped. Companion reads options.txt itself once it connects and the page or labels ask.
• The first screen that closes after the game starts always sends once, since there is no snapshot yet. That costs one read of an unchanged file and tells nobody.
• A mod changing keys without a screen, or without saving options.txt, is not told. Companion shows what the file holds, which is what persists.

Protocol

KEY_ASSIGNMENTS = 52, mod to Companion. Protocol 42; the golden hello bytes are updated.

Tests

:protocol:test, :mod:test and :companion:test are green locally. New: ProjectScopeMessagesTest.theGameSavingChangedKeysHasTheKeysReadAgain, along the real route (the message reaches the project, the keys are read again, and followers are told).

Not covered: the mod's screen-closing comparison has no unit test, since it needs a running Minecraft. Not checked live in the game yet.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-01T14:56:48.426971Z	2f87d61	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.