Noticed this recently in 2022.3.11f1 and it's brightening all scenes up considerably where we make use of lighting adjustments. Will this ever be fixed? No workaround seems to work so far.

Over a year and still no solution in sight?
Anyone ever found a work around? This is rather game breaking to be honest.

In 2021.3.6f1 I solved this issue with
Graphics settings -> Shader stripping: Keep All

We still have this same issue in 2021.2.3f1 URP , even saving the lighting asset wont fix it, any help or update with this issue will be rad , cheers \m/

I wanted to add that I made many builds of my game to test things and lighting was all fine in my title screen objects however I made a decision to change the lights into a prefab so I could reuse them in other scenes. This is when I got the darker scene in my next build and ONLY that change was made as far as I am aware. Simply converting the lights already in my scene to a prefab as indicated by the blue text name.
I even tried to change to a new empty scene and then build my game and bug is still there.
SOLUTION: I ended up deactivating the lightprefab but I duplicated the lights within it and moved them out of the prefab into my scene. I rebuild the build even with the title scene open and wallah the lighting was fixed. So maybe Unity can use this to help narrow things down it might be and issue with the prefab system.

The detailed comment I added is apparently considered a different bug, which is now tracked at https://issuetracker.unity3d.com/issues/player-lighting-not-generated-when-building-the-project-using-command-line

If it's specifically command-line builds you're having problems with, not whether the scene's open in the editor, then I guess you should vote on the other issue.

Setting up lighting in editor and fine adjusting not possible anymore.
Please! I need a fix/workaround!

Exactly same problem. This is stopping us from using a build pipeline and are stuck with manual building.

We are seeing this in our project, we use Unity 2020.3.30f1 and we build to Android using batch mode and -executeMethod calling BuildPipeline.BuildPlayer.

I think I'm seeing this, or something like it, in a project I'm working on. Currently, it's targeting 2020.3.28f1. I spent quite a bit of time digging into it to be sure it wasn't a problem on my end, so I have quite a bit of information that might help chase this down, or determine that it's a separate issue that needs reporting separately. This is the closest thing I could find on the tracker, and seems like it could plausibly be the same thing.

The intentional difference between my dark and bright builds is that the light ones are created through the editor, e.g. the Build or Build And Run buttons in the Build Settings window, or via Ctrl+B, and the dark builds are created via the command line, either with a custom build script called via -executeMethod that calls BuildPipeline.BuildPlayer, or via the -buildWindows64Player argument (or equivalent) for platforms that support that. I've not been able to get a dark build via the editor by having a different scene open, though, which doesn't match the description here, hence why I'm not certain it's the same issue.

I've learned the following:
* It's not resolved by creating a new, similar, scene.
* It affects both Windows and WebGL, so presumably other platforms, too.
* Looking at a dark and light Windows build side-by-side in RenderDoc shows the dark build is using UnityBlackCube for environment lighting and reflections, whereas the light build is using the default Unity skybox, as selected in the Environment tab of the Lighting window. I'd take this as evidence that the bright build is the correct one and the dark one is the one with a bug.
* There are no levelN.resS files in the dark build. Copying them from a bright build does not make the dark build bright.
* Copying the levelN file for the relevant scene (without copying the corresponding .resS file) is enough to make a dark build bright.
* Inspecting the levelN file for the affected scene with AssetStudio (which is third-party, so could be incorrect) suggests that the bright build does reference the default skybox cubemap, whereas the dark one does not.
* The behaviour is the same in 2020.3.21.0f1, which I believe is the last 2020 build before the regression here is supposed to have been introduced. I'm not totally sure of that, though. It might mean that this is a totally separate issue, or that the wrong commit's being blamed.

I don't believe enough of Unity's source code is public for a non-staff-member to be able to discover whether this is the same issue or a separate one. If I've judged incorrectly, I'm happy to make a second issue report if someone lets me know.