A method that calls multiple async tasks with error handling, done the right way?
According to my understanding your piece of software can finish in one of the following states:

Succeeded
Failed
Timed out

You are not exposing the ability to cancel it on the top level. So, it is not cancelable.
Your explicit cancellation mechanism is not needed because:

If timeout occurs at the top level then this fact will be available for all async methods, which received the CancellationToken. The built-in BCL functions will check the token's validity so you don't have to worry about it.
SendMessage and Listen are called sequentially. So if former fails then latter won't be called.
After connectAsync your IsCancellationRequested is pointless. If connectAsync succeeded then this property won't be true. If it was not succeeded then you would not reach this line because your Listen function will be aborted.

On the other hand there is one place where it could make sense to check the cancellationToken. That's inside the do-while loop because the ReadLineAsync is not cancellable.
So let's put all this together with these in mind. I've converted your code into C# 8 if you don't mind.
Listen
public async Task&lt;string&gt; Listen(CancellationToken ct)
{
    try
    {
        await using var _pipeClientStream = new NamedPipeClientStream(&quot;.&quot;, &quot;MyListenPipe&quot;, PipeDirection.In, PipeOptions.Asynchronous, TokenImpersonationLevel.Impersonation); 
        await _pipeClientStream.ConnectAsync(ct);

        var sb = new StringBuilder();
        using var reader = new StreamReader(_pipeClientStream);
        do
        {
            ct.ThrowIfCancellationRequested();
            string line = await reader.ReadLineAsync();

            if (line == MessageFooter || line == null)
            {
                break;
            }
            sb.AppendLine(line);

        } while (true);

        return sb.ToString();
    }
    catch
    {
        return &quot;&quot;;
    }
}


The NamedPipeClientStream is IAsyncDisposable that's why I used await using.
The StreamReader is IDisposable that's why I used using.
I've checked the CancellationToken before each ReadLineAsync because it is not cancellable.

SendMessage
public async Task SendMessage(string message, CancellationToken ct)
{
    await using var _pipeClientStream = new NamedPipeClientStream(&quot;.&quot;, &quot;MyPipe&quot;, PipeDirection.Out, PipeOptions.Asynchronous);
    await _pipeClientStream.ConnectAsync(1000, ct);

    await using var writer = new StreamWriter(_pipeClientStream) { AutoFlush = true };
    await writer.WriteLineAsync(message.AsMemory(), ct);
    await writer.WriteLineAsync(MessageFooter.AsMemory(), ct);
}


WriteLineAsync can accept CancellationToken only if it is called with a ReadOnlyMemory or with a StringBuilder. That's why I used AsMemory.
StreamWriter is IAsyncDisposable that's why I used await using.

GetValueUsingNamedPipe
public async Task&lt;string&gt; GetValueUsingNamedPipe(CancellationToken ct)
{
    await SendMessage(&quot;MyMessage&quot;, ct);
    return await Listen(ct);
}


The sendMsg variable is pointless because right after the assignment it is awaited then never used.
I've removed the try-catch block because in that way the TaskCancelledException would be caught here.
So basically if you wish you can inline this method into the CheckForValue

CheckForValue
public async Task&lt;bool&gt; CheckForValue()
{
    const int timeout = 300;
    try
    {
        using var timeoutTokenSource = new CancellationTokenSource(timeout);
        var result = await GetValueUsingNamedPipe(timeoutTokenSource.Token);
        return (result == &quot;WhatIWant&quot;);
    }
    catch (TaskCanceledException) //The actual type will be TimedOutTaskCanceledException
    {
        return false;
    }
    catch (Exception) // GetValueUsingNamedPipe failed for some reason
    {
        return false;
    }
}


All the explicit cancellation calls are gone, because they are not needed. The cancellation fact will be propagated all the related parties and it will manifest in a TaskCancelledException.
So it is much cleaner now. :D

I hope it helped you a bit.