Not sure if still the case but Cloth Config may have third party downloads disabled, which is a terrible decision to make as a library mod.

Hey there, in case you're seeking an alternative, I didn't want to redo my config system when initially porting to Fabric or create an unhealthy amount of abstractions, so I just ported Forge's config api/system to Fabric as a standalone library.

The beauty of it is even every package name is the same, so the library can already be applied at a common/shared level so config code doesn't even have to exist multiple times for each mod loader. Only config registration is where loader specific code is required, but that's just a single line usually.

Here is an example project where using Forge Config API Port is demonstrated (not that there's something special, after all it's a direct port from Forge, but it mainly shows that configuration does indeed work in the common sub project): https://github.com/Fuzss/impactfulweather/blob/multiloader/Common/src/main/java/shadowmaster435/impactfulweather/config/ClientConfig.java

I believe the situation has since been resolved and until something POJO-based overtakes Cloth Config I'll just stick with it.

The reason I'm hesitant to switch to something like Forge Config API Port is that it adds a hard dependency on a non-trivial amount of code that I would then have to reference in Balm, meaning I'd also depend on it for updating my mods to newer versions. With Cloth Config and other config mods that work based on class reflection I only have a bunch of annotations to swap out and otherwise they're mostly interchangeable.