NG0203: Why inject() Fails Outside an Injection Context

The window, and when it closes#

The full message is inject() must be called from an injection context. The injection context is the runtime window where the current injector is reachable, and the docs are exact about when it exists: during construction of a class the DI system instantiates, in the field initializers of that class, in a useFactory or InjectionToken factory, and inside any stackframe run through runInInjectionContext. That is the whole list.

The trap is that the window is narrow. It is open while Angular is building the instance and closed the moment construction finishes. The API reference says it plainly: calls to inject() are disallowed after a class instance was already created, in methods including lifecycle hooks. So the question is never *can I inject this type*; the provider exists. The question is *was the injection context still open when this line ran*.

Where inject() works, and where it throws#

Most NG0203 reports come from one of a short list of call sites. The pattern is consistent: code that runs synchronously while Angular builds the class is fine, and code deferred to a callback, a timer, a stream, or a method body has already missed the window.

Read the table by call site, not by type. The type is injectable in every row. What changes is whether the line executes inside the construction window or after it.

The traps that look harmless#

The first trap is inject() inside a subscribe. The constructor looks fine, the call site looks fine, but the callback runs when the value arrives, not when the class is built, and by then the context is closed.

The second is the async route guard. A CanActivateFn runs in an injection context when it starts, so the first inject() is fine. Put an await before the next one and you have crossed out of the synchronous window: the docs state inject is only usable synchronously and cannot be used after any await points. The third is the quiet one: a private getter or a helper method that calls inject(). It reads like field code, but it executes on access, long after construction.

export class OrdersComponent {
  private readonly orders = inject(OrderService);

  ngOnInit() {
    this.orders.changes$.subscribe(() => {
      // NG0203: the callback runs after construction
      const logger = inject(LoggerService);
      logger.track('orders changed');
    });
  }

  // NG0203: a getter runs on access, not during construction
  get currency() {
    return inject(LOCALE_ID) === 'pt-BR' ? 'BRL' : 'USD';
  }
}

The fixes, ranked#

Start at the top of this list and only move down when the case forces you to. Most NG0203 disappears at step one, because the injected reference did not need to be resolved late; the code was just written late.

First, move the inject() to a field initializer or capture the reference once at construction and use it later. The field holds the dependency; the callback uses the field. Second, when you genuinely need resolution inside deferred code (a dynamically chosen token, a per-call injector), capture the Injector at construction and call runInInjectionContext(injector, () => inject(X)) where the work runs. Third, for the specific RxJS-cleanup case, takeUntilDestroyed accepts an explicit DestroyRef, so you can capture inject(DestroyRef) once and pass it into the operator outside the context.

I would refuse the reflex fix of wrapping every late call in runInInjectionContext. It silences NG0203, but it usually means the design deferred a decision that belonged at construction. When I see it in review, I ask what is actually dynamic. If the answer is *nothing*, the reference should be a field, not a runtime lookup.

export class OrdersComponent {
  private readonly orders = inject(OrderService);
  // Capture once, in the construction window:
  private readonly logger = inject(LoggerService);
  private readonly destroyRef = inject(DestroyRef);

  ngOnInit() {
    this.orders.changes$
      .pipe(takeUntilDestroyed(this.destroyRef))
      .subscribe(() => this.logger.track('orders changed'));
  }
}

runInInjectionContext, and the await that breaks it#

When the lookup truly is deferred, inject the Injector (or EnvironmentInjector) at construction and reopen the context where you need it. The signature is runInInjectionContext(injector, fn): it runs fn with that injector available, so inject() works inside the closure and returns its result.

There is one edge that fools people, and it is worth saying out loud: the context runInInjectionContext opens is synchronous. The moment you await inside the closure, you fall out of it, and an inject() after the await throws NG0203 again. So resolve everything you need before the first await, then do the async work. This is the same rule that bites async route guards, and it is the single most common reason a runInInjectionContext fix still fails.

export class ReportExporter {
  private readonly injector = inject(Injector);

  exportLater() {
    setTimeout(() => {
      runInInjectionContext(this.injector, () => {
        // Resolve synchronously, before any await:
        const http = inject(HttpClient);
        const url = inject(REPORT_URL);
        http.get(url).subscribe();
      });
    }, 1000);
  }
}