am i missing something?

I will have to investigate haven't heard of this as an issue.

I doubt the plugin is to blame here. The issue is that as of the recent Rust update, if a player is not authorized to a code lock, they see the "Unlock" prompt instead or the "Open" prompt. If you activate that prompt, it will do what it says. If you want to open the door instead of unlock it, hold down the use button and select the "Open" action instead.

As for how the plugin can mitigate the issue, it would likely have to add the admin to the code lock to get the preferred prompt to be displayed by default.

To be honest, I like how this Rust update affects how the Vanish plugin works now: If you have the vanish.unlock permission, you need to hold E and select Open to open the door, simply pressing E will bring up the code lock input prompt. This for example prevents admins from accidentally opening doors if they want to open a box very close to a door, and thus won't attract attention of nearby players. Of course, actually unlocking the lock and changing the LED to green still requires entering the code.

Now with Master Key, pressing E will immediately unlock the code lock and change the LED to green. I find this behavior to be worse and prone to mistakes, accidentally leaving code locks unlocked and such. It would be much better if it worked the same way as how Vanish is handling this.

But.... then again, you would lose the ability to actually unlock the lock and change the LED to green if that is actually what you want to do... so, its kind of a scuffed situation right now for the Master Key plugin to be in. I personally always have the functionality turned off, and I toggle it on/off as needed via the /mk chat command.

I was thinking of a few ways to fix this, but not sure how feasible these are:

1. As suggested by WhiteThunder: Have the admin be added to the code lock as to restore the old behavior.
NOTE: However, is this not going to be problematic when using console commands to see who is authed on code locks? It would pollute the auth lists with extraneous admin entries, would it not? Also, what logic would be used to decide when to add the admin to the lock, and potentially remove it again from the lock?

2. Basically have it work like how Vanish is doing it, but also add new chat (and console?) commands to unlock/lock and change LEDs to green/red of the lock you are currently looking at (similar to ent unlock/lock), if that is actually what the admin wants to do.

3. There are 2 ways to unlock now: Simply pressing E on the door to bring up the code prompt, and holding E and selecting Unlock in the radial menu. Are both of these hookable in a separate way? If yes, this would add the ability to prevent accidental unlocks by admins. This could work in the following way: Pressing E so the prompt comes up as expected, stopping accidental unlocks. And then holding E and selecting Unlock in the radial menu would actually unlock the lock and change it to the green LED. Basically making it work like Vanish, but with the added ability to unlock via the menu.

Number 3 would be the peferred way, for me at least. If this is possible, it could even be implemented with a new config option to switch between the behaviors described in 1 and 3 depending on admin/owner preferences for their servers.

MasterKey quit working after the last wipe and hasn't been updates for 2 years. Could someone get Fastburst to update this.