Hi. Are you using any user-CSS or gadget/user-scripts here? [Or: Can you reproduce this whilst logged-out?]. I can't see anything obvious in your global.css, but maybe there's something harder for me to see elsewhere.
Context: I experienced this bug a few months ago when I was experimenting with increasing the font-size in the edit-window, via custom user-CSS. [I was trying to force it to match my Appearance-menu preferences on Desktop for the "standard" font-size. Here's the code I removed from my custom user-CSS which fixed this bug, but leaves me with too-small a font].
[Sidenote: I am not a dev. I'm just trying to help clarify the origin of this bug.]

Thanks! It was a font face rule in my global.css. I wonder if Community Tech would want to see if the extension could be improved or if this task should be declined.

Change #1247191 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/extensions/CodeMirror@master] ve.ui.CodeMirror: inherit font-family and font-size

https://gerrit.wikimedia.org/r/1247191

In T418793#11665369, @Quiddity wrote:

Context: I experienced this bug a few months ago when I was experimenting with increasing the font-size in the edit-window, via custom user-CSS. [I was trying to force it to match my Appearance-menu preferences on Desktop for the "standard" font-size. Here's the code I removed from my custom user-CSS which fixed this bug, but leaves me with too-small a font].

The small font was intentionally enforced in r1216878 to fix T412117. However, if larger fonts are favored, we may consider overriding CodeMirror's font size in MobileFrontend styles.

Change #1247191 merged by jenkins-bot:

[mediawiki/extensions/CodeMirror@master] ve.ui.CodeMirror: inherit font-family and font-size

https://gerrit.wikimedia.org/r/1247191

In T418793#11666279, @MusikAnimal wrote:

The attached patch will fix trivial font overrides like p { font-family: 'Helvetica'; font-size: 3em; }, but it's still possible to override if the rules are specific enough or !important is used. I'd rather avoid using !important in the CodeMirror CSS unless we have to. Likewise, those who make JS/CSS overrides know (or should know) it's possible to break things, so hopefully this will suffice as a compromise.

Yeah, sounds great, thank you.

I assume @Redmin (and perhaps @Quiddity as well) don't normally use the 2017 editor when editing, or else they would see this issue there too…

Yes, I use the old Wikitext editor.

In T418793#11666398, @Bhsd wrote:

The small font was intentionally enforced in r1216878 to fix T412117. However, if larger fonts are favored, we may consider overriding CodeMirror's font size in MobileFrontend styles.

If you mean user-customizable, then yes please! I would like all relevant aspects of the sites [long-form text content] to scale appropriately when I adjust my Appearance-menu text-size preferences.
[When I was younger, I strongly wanted the Small fonts. Now my eyes are aging, and I need/appreciate the new Standard font size. In future years, I will probably want the Large size.]
Especially the content in the edit-boxes, but also other long-form text content, such as the other Namespaces that are not yet default (e.g. the Manual: namespace on mediawiki-wiki).

So long as the VisualEditor font size and CodeMirror font size match, it should be fine. If they don't, we get misalignment. The Editing team may disagree however, see r1100398 for example.

The core issue is that the CM surface is overlayed on top of the VE surface, so the styles must match exactly. Getting rid of this "hack" is something I hope to work on at the Wikimedia-Hackathon-2026. I still need to create tasks, and I also can't make promises a proper fix will be possible, but I shall try! :-P Until then, we may be stuck with precisely always the same monospace font when editing with the 2017 editor + CM, at the discretion of the Editing team.

Relatedly, I had wondered if we could respect the 2017 editor preference in DiscussionTools, such that "Enable editing tools in source mode" will use WikiEditor or 2017 editor based on the preference. If that were the case, the bug documented here would never have happened. It might be worth looking into (in a separate task), but would also subject to approval by Editing.