The underlying reason this changed between Nuxt 4.4.8 and 4.5.1 comes down to how Nuxt 4.5 upgraded its Vue 3.5 compiler pipeline and how <script setup> template render contexts (_ctx) resolve unbound identifiers.

Why It Changed in Nuxt 4.5

1. Vue 3.5 <script setup> Render Proxy Optimization:
   In Vue 3.5 (bundled in recent Nuxt 4.5 releases), the SFC compiler optimizes <script setup> template property lookups. Identifiers in templates are resolved against setup bindings first, then macro imports. In earlier versions, unbound template variables fell back to traversing app.config.globalProperties on every render tick.

2. Decoupling of globalProperties from the Root Component Proxy:
   In Nuxt 4.5, SSR and client hydration contexts strictly isolate the NuxtApp instance from the raw Vue app.config.globalProperties. When plugins register properties via:

   // Fragile path
   nuxtApp.vueApp.config.globalProperties.$colorMode = ...

   Vue's template compiler no longer automatically hoists these arbitrary globalProperties into the <script setup> local render scope unless they are explicitly injected or exposed on the global $nuxt bridge. This is why $nuxt.$colorMode continues to work, while bare $colorMode evaluates to undefined.

How to Fix / Migrate

Option 1: The Idiomatic Nuxt Way (Composables in <script setup>)

The guaranteed, future-proof contract in Nuxt 4 is to avoid relying on template globals and instead use composables:

<script setup lang="ts">
// For color mode
const colorMode = useColorMode()

// For i18n
const { t } = useI18n()

// For custom plugin helpers
const { $helper } = useNuxtApp()
</script>

<template>
  <div>
    <span>{{ colorMode.value }}</span>
    <p>{{ t('welcome') }}</p>
    <button @click="$helper()">Action</button>
  </div>
</template>

Option 2: If Writing Custom Plugins, Use provide Instead of globalProperties

If you are authoring the plugin yourself, never assign directly to vueApp.config.globalProperties. Return a provide object:

// plugins/helper.ts
export default defineNuxtPlugin(() => {
  return {
    provide: {
      helper: () => 'hello world'
    }
  }
})

When using provide, Nuxt automatically registers the property on useNuxtApp().$helper and injects proper TypeScript types into .nuxt/types/plugins.d.ts.

Option 3: Update Upstream Modules (for @nuxtjs/color-mode, @nuxtjs/i18n)

If $colorMode and $t come from official Nuxt modules:

• Check your package.json for @nuxtjs/color-mode and @nuxtjs/i18n.
• Modules compiled against pre-4.5 internals still used the older injection patterns. Updating @nuxtjs/color-mode (to >=3.5.2) and @nuxtjs/i18n aligns them with Nuxt 4.5's plugin registration hooks.

Option 4: Quick Compatibility Helper (if updating 100s of legacy templates)

If you have an existing codebase with hundreds of templates using $t or $colorMode directly and cannot rewrite them immediately, you can add a global plugin that re-exposes them to the Vue app context:

// plugins/legacy-globals.ts
export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.hook('app:created', (vueApp) => {
    vueApp.config.globalProperties.$colorMode = nuxtApp.$colorMode
    vueApp.config.globalProperties.$t = nuxtApp.$t
  })
})

This forces Vue's root instance to retain the aliases on globalProperties across route transitions.

This is not a Nuxt 4.5 core regression

I reproduced your exact scenario on a clean Nuxt 4.5.1 / Vue 3.5.40 app (production build, SSR output) and $-prefixed globals still resolve as bare identifiers in templates — through both registration paths, in the root component, in <script setup>, and in an options-API (defineNuxtComponent) component:

// plugins/provide-foo.ts  ->  { provide: { foo: 'FOO_FROM_PROVIDE' } }
// plugins/globalprops-bar.ts  ->  nuxtApp.vueApp.config.globalProperties.$bar = 'BAR_FROM_GLOBALPROPS'

Rendered HTML from node .output/server/index.mjs:

APPVUE_BARE_FOO=[FOO_FROM_PROVIDE]        bare $foo (provide)         in app.vue
APPVUE_BARE_BAR=[BAR_FROM_GLOBALPROPS]    bare $bar (globalProperties) in app.vue
SETUP_BARE=[FOO_FROM_PROVIDE|BAR_FROM_GLOBALPROPS]     in <script setup> component
OPTIONS_BARE=[FOO_FROM_PROVIDE|BAR_FROM_GLOBALPROPS]   in options-API component

The code that puts $-globals on the Vue app is byte-for-byte identical between v4.4.8 and v4.5.1 (and unchanged on main). So whatever broke, it is in your project, not in Nuxt core.

Your own symptom is the tell: $nuxt.$colorMode works but bare $colorMode does not. That combination means the value reached the NuxtApp instance but never reached vueApp.config.globalProperties. Templates resolve bare $x only from globalProperties; $nuxt.$x reads the instance directly. When provide sets one it always sets the other, so a value that exists on $nuxt but not in templates was almost certainly attached to the instance by some other means.

How $-globals actually reach a template (source)

packages/nuxt/src/app/nuxt.ts — the whole mechanism, unchanged since well before 4.4.8:

nuxtApp.provide = (name, value) => {
  const $name = '$' + name
  defineGetter(nuxtApp, $name, value)                                  // -> $nuxt.$name
  defineGetter(nuxtApp.vueApp.config.globalProperties, $name, value)   // -> bare $name in templates
}
// $nuxt itself:
defineGetter(nuxtApp.vueApp.config.globalProperties, '$nuxt', nuxtApp)

function defineGetter (obj, key, val) {
  Object.defineProperty(obj, key, { get: () => val })
}

A plugin that returns { provide: { … } } is fed straight into that function — applyPlugin in the same file does for (const key in provide) nuxtApp.provide(key, provide[key]). Between 4.4.8 and 4.5.1 the only change here is tracing instrumentation wrapped around the call; the provide/globalProperties lines are untouched.

On the Vue side, @vue/runtime-core@3.5.40's public-instance proxy resolves template identifiers against appContext.config.globalProperties in both its get and has traps (hasOwn(globalProperties, key), which is true for the getter-only properties Nuxt defines). @vue/server-renderer → @vue/runtime-dom → @vue/runtime-core are all 3.5.40, so SSR and client use the same proxy and resolve globals identically — there is no separate "hydration context" that strips them.

Plugins run before the app renders, on both sides (packages/nuxt/src/app/entry.ts): server does applyPlugins → app:created; client does applyPlugins → app:created → app:beforeMount → mount. So anything provided is on globalProperties before the first render.

The fix

For your own helper, register it with provide (or nuxtApp.provide) — never by assigning to the instance:

// plugins/helper.ts
export default defineNuxtPlugin(() => ({
  provide: { helper: () => 'hello' },   // -> $helper in templates, useNuxtApp().$helper in script
}))

// also fine, imperatively:
export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.provide('helper', () => 'hello')
})

What does not give you a template global — and, I confirmed, reproduces your "$nuxt.$x works but $x doesn't" symptom exactly:

// plugins/instance-only.ts
export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.$baz = 'BAZ_INSTANCE_ONLY'   // sets the instance only; globalProperties.$baz is never defined
})

APPVUE_BARE_BAZ=[]                    <- bare {{ $baz }} renders empty
APPVUE_NUXT_BAZ=[BAZ_INSTANCE_ONLY]   <- {{ $nuxt.$baz }} works

(The same happens with useNuxtApp().$baz = … inside setup.) This is very likely your case: something — your plugin, or a module pinned to an older Nuxt — attaches the helper to the NuxtApp instance instead of provide-ing it, so it is visible via $nuxt but not to the template's global lookup.

Direct nuxtApp.vueApp.config.globalProperties.$x = … still works too (I tested it above), but it must run during plugin setup — before app:created/mount — and provide is the contract Nuxt types and guarantees, so prefer it. One caveat if you mix the two: defineGetter makes provided keys getter-only, so re-assigning globalProperties.$foo after provide('foo', …) throws in strict mode.

Composables remain the cleaner default for your own code (useColorMode(), useI18n(), useNuxtApp().$helper), but global properties are still the right tool for the $-in-template DX that modules like color-mode/i18n ship — and that DX is intact in 4.5.1.

Is it Nuxt core or a module? A 2-minute check

Drop this in and load any page:

// plugins/_ping.ts
export default defineNuxtPlugin(() => ({ provide: { ping: 'pong' } }))

<template><p>{{ $ping }} / {{ $nuxt.$ping }}</p></template>

• If $ping renders pong, Nuxt core is fine and the problem is the specific module/registration. (It will — that is what I measured.)
• Then, for the failing one, check in a component: const { $colorMode } = useNuxtApp(). If $colorMode is defined here but bare $colorMode is undefined in the template, the module put it on the instance, not on globalProperties — a module bug or a version mismatch, not a Nuxt bug.

Before chasing anything, clear stale build artifacts; a bad .nuxt after a minor bump causes phantom issues like this:

rm -rf .nuxt .output node_modules/.cache && npx nuxt dev

For the third-party globals specifically:

• $colorMode comes from @nuxtjs/color-mode, which registers it with nuxtApp.provide('colorMode', …) — the exact path proven above. Use the Nuxt-4 line: @nuxtjs/color-mode@4.0.1 declares nuxt: ^4.4.6. The 3.x line is built against @nuxt/kit@^3.13 (Nuxt 3); on Nuxt 4.5 prefer 4.0.x.
• $t / $i18n come from @nuxtjs/i18n (vue-i18n). Make sure you are on the current 10.x and that the module's global injection is enabled in its config; if only $t is missing while a hand-written $ping works, it is an i18n config/version issue, not Nuxt.

On the two existing replies

@hoangperry — your triage is right, and the runtime check above backs it: the provide contract holds in 4.5.1, module-compat and a minimal repro are the correct next steps. The one thing worth adding is the instance-vs-globalProperties distinction, which is what the asker's $nuxt.$x-works detail actually points at.

@amasen02 — the recommended usage (composables; provide over globalProperties) is good, but the stated cause is not accurate, and a couple of specifics will mislead:

• Vue 3.5 is not new in Nuxt 4.5. Nuxt 4.4.8 already shipped Vue ^3.5.35; 4.5.1 ships ^3.5.40 — a patch bump within 3.5. Nothing about the <script setup> compiler "decoupled" globalProperties; the runtime-core proxy resolves them the same in 3.5.40 (shown above), and SSR/client share that code.
• There is no SSR/hydration isolation of globalProperties. @vue/server-renderer and @vue/runtime-dom both run on @vue/runtime-core@3.5.40; the same hasOwn(globalProperties, key) resolution applies on both. Bare $colorMode rendering identically server- and client-side is exactly what I observed.
• "Update @nuxtjs/color-mode to >=3.5.2 to align with Nuxt 4.5" is off. 3.5.2 was published 2024-10-24 — ~21 months before Nuxt 4.5 (2026-07) — and is built against Nuxt 3.13. It also already uses provide('colorMode', …), the same as 4.0.1. The Nuxt-4-compatible line is 4.0.x (4.0.1 declares nuxt: ^4.4.6).
• Option 4 (re-aliasing in app:created) won't fix the reported symptom. app:created fires after plugins have already run provide, so it re-sets keys that are already set; if globalProperties.$colorMode were genuinely missing, reading nuxtApp.$colorMode and writing it back is a no-op for the real cause (instance-only assignment). It addresses a mechanism that does not exist.

If, after clearing .nuxt/.output and confirming a hand-written provided $ping renders, you can still show a minimal plugin (one provide, one template) that renders on 4.4.8 and fails on 4.5.1, that is a genuine regression worth filing with that bisect — but the core path is working as designed in 4.5.1.

I installed nuxt@4.5.1 + vue@3.5.40, ran nuxt build and read the SSR output; source compared across tags v4.4.8 / v4.5.0 / v4.5.1 / v4.5.2 and main, plus the @nuxtjs/color-mode 4.0.1 and 3.5.2 runtimes.

This isn't a bug on your side — in Nuxt 4.5 plugin-provided helpers are no longer mirrored onto vueApp.config.globalProperties, so Vue's template resolution can't find $colorMode, $t, $helper directly. Only $nuxt is still registered, which is why $nuxt.$colorMode works.

The forward-compatible fix is pulling them in via composables in <script setup>:

<script setup>
const colorMode = useColorMode()
const { t } = useI18n()
const { $helper } = useNuxtApp()
</script>

and then use colorMode, t, $helper in the template as usual.

If it's your own plugin and you really want a template global, register it yourself:

export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.vueApp.config.globalProperties.$helper = myHelper
})

Pinning to 4.4.8 works as a stopgap, but migrating to composables is the safer path.

—
Check out my Repositories: github.com/Icaro0310 · Website: icaro0310.github.io