diff --git a/src/DodoSSH.Client.Shell/ViewModels/TransfersViewModel.cs b/src/DodoSSH.Client.Shell/ViewModels/TransfersViewModel.cs
index a1f4078..cb00adf 100644
--- a/src/DodoSSH.Client.Shell/ViewModels/TransfersViewModel.cs
+++ b/src/DodoSSH.Client.Shell/ViewModels/TransfersViewModel.cs
@@ -250,6 +250,7 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
 {
     private readonly ISftpSessionFactory sftp;
     private readonly FileTransferQueue queue;
+    private readonly Action<Action> post;
 
     private VaultViewModel? vault;
     private VaultKnownHostStore? knownHosts;
@@ -269,9 +270,27 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
 
     private bool disposed;
 
-    internal TransfersViewModel(ISftpSessionFactory sftp, TimeProvider clock)
+    /// <param name="sftp">Opens SFTP sessions.</param>
+    /// <param name="clock">Time source, for transfer rates and timestamps.</param>
+    /// <param name="post">
+    /// Runs an action on the thread this view model's collections are read from. Defaults to the UI thread's
+    /// dispatcher, which is the answer in every real head.
+    /// <para>
+    /// A delegate rather than <c>Dispatcher.UIThread</c> reached directly, for the reason
+    /// <c>VaultViewModel</c>'s clipboard is one. <c>Dispatcher.UIThread</c> is process-wide and belongs to
+    /// whichever thread touched it first, so a test that posts through it is asserting on a queue owned by
+    /// some other test's thread — which passes or throws "the calling thread cannot access this object"
+    /// depending on the order a runner happened to schedule its classes in. Running the action inline
+    /// removes the thread from the question rather than making the test guess it right.
+    /// </para>
+    /// </param>
+    internal TransfersViewModel(
+        ISftpSessionFactory sftp,
+        TimeProvider clock,
+        Action<Action>? post = null)
     {
         this.sftp = sftp;
+        this.post = post ?? (action => Dispatcher.UIThread.Post(action));
 
         // The supplier answers with whatever session is current at the moment a transfer starts, which is
         // what lets a queue survive a disconnect and reconnect without every queued row failing.
@@ -1296,7 +1315,7 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
     /// instead of one for the first change and one for the rest.
     /// </remarks>
     private void OnTransferChanged(object? sender, TransferChangedEventArgs e) =>
-        Dispatcher.UIThread.Post(() =>
+        post(() =>
         {
             if (Transfers.FirstOrDefault(row => row.Id == e.Transfer.Id) is { } existing)
             {
diff --git a/tests/DodoSSH.Client.App.Tests/TransferQueueingTests.cs b/tests/DodoSSH.Client.App.Tests/TransferQueueingTests.cs
index b9318e0..3882ee2 100644
--- a/tests/DodoSSH.Client.App.Tests/TransferQueueingTests.cs
+++ b/tests/DodoSSH.Client.App.Tests/TransferQueueingTests.cs
@@ -1,4 +1,4 @@
-using Avalonia.Threading;
+using System.Collections.Concurrent;
 using DodoSSH.Client.Shell.ViewModels;
 using DodoSSH.Client.Ssh;
 using NSubstitute;
@@ -26,10 +26,33 @@ public sealed class TransferQueueingTests : IDisposable
     private readonly string directory =
         Path.Combine(Path.GetTempPath(), $"dodossh-drop-{Guid.CreateVersion7():N}");
 
-    private readonly TransfersViewModel transfers =
-        new(Substitute.For<ISftpSessionFactory>(), TimeProvider.System);
+    /// <summary>What the view model has posted and <see cref="Queued"/> has not run yet.</summary>
+    /// <remarks>
+    /// A queue of this test's own, standing in for the dispatcher — which is what it replaces. Draining
+    /// <c>Dispatcher.UIThread</c> meant depending on which thread a runner happened to touch that
+    /// process-wide object from first, and once another class got there first every test here died on
+    /// "the calling thread cannot access this object" having asserted nothing about transfers at all.
+    /// <para>
+    /// A queue rather than a poster that runs the action inline, and the difference is not stylistic: the
+    /// transfer queue raises <c>Changed</c> from its pump thread as well as from the call that enqueued,
+    /// so inline execution would have a background thread adding rows to an <c>ObservableCollection</c>
+    /// while the test reads it. Draining keeps every mutation on the thread doing the asserting, which is
+    /// the one thing the dispatcher was providing that is worth keeping.
+    /// </para>
+    /// </remarks>
+    private readonly ConcurrentQueue<Action> posted = new();
 
-    public TransferQueueingTests() => Directory.CreateDirectory(directory);
+    private readonly TransfersViewModel transfers;
+
+    public TransferQueueingTests()
+    {
+        Directory.CreateDirectory(directory);
+
+        transfers = new TransfersViewModel(
+            Substitute.For<ISftpSessionFactory>(),
+            TimeProvider.System,
+            posted.Enqueue);
+    }
 
     /// <inheritdoc />
     public void Dispose()
@@ -162,17 +185,51 @@ public sealed class TransferQueueingTests : IDisposable
         transfers.Status.ShouldContain("1 folder was skipped");
     }
 
+    /// <remarks>
+    /// Queueing is reachable from any thread — a drop is handled on the UI thread, a retry is not — and
+    /// nothing about it may depend on which one. Worth stating because the version of this class that
+    /// drained <c>Dispatcher.UIThread</c> did depend on exactly that, and said so only by failing in CI on
+    /// a machine whose scheduling differed. The draining still happens on the test's own thread, as
+    /// <see cref="Queued"/> explains; what is asserted here is the half that has no business caring.
+    /// </remarks>
+    [Fact]
+    public void QueueingFromAnotherThread_StillEnqueues()
+    {
+        Exception? failure = null;
+
+        var thread = new Thread(() =>
+        {
+            try
+            {
+                Connected();
+                transfers.QueueUploads([File("one.txt")]);
+            }
+            catch (Exception exception)
+            {
+                failure = exception;
+            }
+        });
+
+        thread.Start();
+        thread.Join();
+
+        failure.ShouldBeNull();
+        Queued().ShouldHaveSingleItem();
+    }
+
     /// <summary>The queue's rows, once the posts that create them have been let run.</summary>
     /// <remarks>
-    /// <c>TransfersViewModel</c> adds a row from the queue's own <c>Changed</c> event, which it marshals
-    /// through <c>Dispatcher.UIThread</c> because the queue raises it from a pump thread. There is no
-    /// Avalonia application here to drain that, so the posts are run by hand — the alternative is asserting
-    /// on the status line alone, which is a string this code wrote about itself and proves nothing about
-    /// anything having been enqueued.
+    /// <c>TransfersViewModel</c> adds a row from the transfer queue's own <c>Changed</c> event, which it
+    /// marshals because the queue raises it from a pump thread. Nothing drains that here, so the posts are
+    /// run by hand — the alternative is asserting on the status line alone, which is a string this code
+    /// wrote about itself and proves nothing about anything having been enqueued.
     /// </remarks>
     private IReadOnlyList<TransferRowViewModel> Queued()
     {
-        Dispatcher.UIThread.RunJobs();
+        while (posted.TryDequeue(out var action))
+        {
+            action();
+        }
 
         return transfers.Transfers;
     }