The following code will alternative between registering a command every time commands are reloaded.

public class ExampleMod implements ModInitializer {

    public static boolean registered = true;
    @Override
    public void onInitialize() {

        CommandRegistrationCallback.EVENT.register((dispatcher, dedicated) -> {
            if(!registered){
                registered = true;
                return;
            }
            registered = false;
            dispatcher.register(CommandManager.literal("custom").executes(context -> {
                context.getSource().sendFeedback(Text.of("Success"), false);
                return Command.SINGLE_SUCCESS;
            }));
        });

    }
}

This produces the following results in game:

Just tested it, I can confirm that the same thing happens on vanilla (used remote JVM debug to register the /chase command), so not a bug with fabric's command api (which I thought it was).

While having this fixed would be nice, I am also not sure if it falls under the scope of the fabric API, so feel free to close this.

Ok, thanks for the response, and the issue. 👍

I think I will close this as I do think this is out of scope. It shouldnt be too hard for your mod to send the packet on reload.

Im unsure if this is an issue with Fabric/something fabric should fix. I dont believe we or vanilla have every supported dyamic commands like this. Re-logging should fix it as vanilla will send the command tree packet again (See PlayerManagaer.sendCommandTree)

A fix would be for fabric to send this after reloading, I think this might be out of scope of what fabric API should be doing. Im open to feedback on this.