Dependency injection of IHttpContextAccessor vs passing parameter up the method chain

Our application calls many external API's which take a session token of the current user as input. So what we currently do is in a controller, get the session token for the user and pass it into a service which in turn might call another service or some API client. To give an idea, we end up with something like this (example is .NET but something similar is I think possible in Java)

public IActionResult DoSomething(string something)
{
  this.someService.DoSomethingForUser(this.HttpContext.SessionToken, something);
  return View();
}

And then we have

public class SomeService
{
  private readonly IApiClient apiClient;

  public SomeService(IApiClient apiClient)
  {
    this.apiClient = apiClient;
  }

  public void DoSomethingForUser(string sessionToken, something)
  {
    this.apiClient.DoSomethingForUser(sessionToken, something);
  }
}

It can also happen that in SomeService another service is injected which in turn calls the IApiClient instead of SomeService calling IApiClient directly, basically adding another "layer".

We had a discussion with the team if it isn't better to instead of passing the session token, inject it using DI so you get something like this:

public IActionResult DoSomething(string something)
{
  this.someService.DoSomethingForUser(something);
  return View();
}

And then we have

public class SomeService
{
  private readonly IUserService userService;
  private readonly IApiClient apiClient;

  public SomeService(IUserService userService, IApiClient apiClient)
  {
    this.userService = userService;
    this.apiClient = apiClient;
  }

  public void DoSomethingForUser(string something)
  {
    this.apiClient.DoSomethingForUser(userService.SessionToken, something);
  }
}

The IUserService would have an IHttpContextAccessor injected:

public class UserService : IUserService
{
  private readonly IHttpContextAccessor httpContextAccessor;

  public UserService(IHttpContextAccessor httpContextAccessor)
  {
    this.httpContextAccessor = httpContextAccessor;
  }

  public string SessionToken => httpContextAccessor.HttpContext.SessionToken;
}

The benefits of this pattern are I think pretty clear. Especially with many services, it keeps the code "cleaner" and you end up with less boilerplate code to pass a token around.

Still, I don't like it. To me the downsides of this pattern are more important than its benefit:

• I like that passing the token in the methods is concise. It is clear that the service needs some sort of authentication token for it to function. I'm not sure if you can call it a side effect but the fact that a session token is magically injected three layers deep is impossible to tell just by reading the code
• Unit testing is a bit more tedious if you have to Mock the IUserService
• You run into problems when calling this in another thread, e.g. calling SomeService from another thread. Although these problems can be mitigated by injecting another concrete type of IUserService which gets the token from some place else, it feels like a chore.

To me it strongly feels like an anti pattern but apart from the arguments above it is mostly a feeling. There was a lot of discussion and not everybody was convinced that it was a bad idea. Therefor, my question is, is it an anti pattern or is it perfectly valid? What are some strong arguments for and against it, hopefully so there can be not much debate that this pattern is indeed, either perfectly valid or something to avoid.