diff --git a/.codex/flaky-test-triage.md b/.codex/flaky-test-triage.md
index 965f6a707c..d51a9bd977 100644
--- a/.codex/flaky-test-triage.md
+++ b/.codex/flaky-test-triage.md
@@ -51,10 +51,12 @@ Older failures also appeared on Linux, but the repeated cross-PR signal is stron
 - Windows arm64 failure: `all::suite::fuzzy_file_search::test_fuzzy_file_search_session_multiple_query_updates_work` timed out during app-server `initialize`, before the fuzzy-search session logic started.
 - Commit `d017d0fc3` fixed those two Windows-specific flakes, but the first in-process fuzzy-search harness revision introduced a new ordering regression on Linux.
 - Linux failure: `all::suite::fuzzy_file_search::test_fuzzy_file_search_session_update_works_without_waiting_for_start_response` received an error instead of a response because `sessionUpdate` could be enqueued ahead of `sessionStart`.
+- Commit `4195e7e80` fixed that ordering race, but the new public in-process request helpers returned a private type alias and tripped the `Lint/Build` matrix before the remaining test jobs could finish.
 - Current patch set:
   - Pin the standalone shell test to `cmd.exe` on Windows so it validates reference-context isolation without depending on PowerShell startup behavior.
   - Replace the fuzzy-file-search suite's spawned `codex-app-server` harness with the in-process app-server runtime so the tests still exercise request/notification behavior without the flaky stdio startup path.
   - Preserve in-process request order by enqueueing requests synchronously and storing a pending-response handle instead of spawning `sender.request(...)` tasks that can race.
+  - Inline the public in-process request return types so the request-order fix no longer leaks a private alias through the `app-server` public API.
 - Rationale: these failures are test-harness flakes, not product behaviors. The fixes keep the assertions intact and remove environment-sensitive startup and ordering hazards instead of stretching timeouts.
 
 ## Constraints
@@ -85,3 +87,4 @@ Older failures also appeared on Linux, but the repeated cross-PR signal is stron
 | `761363008` | Annotate nextest failures in CI | failed | Run `23083522224` flipped to a new `Tests — windows-x64 - x86_64-pc-windows-msvc` failure while `Tests — windows-arm64 - aarch64-pc-windows-msvc` and every non-test job passed. The new annotations proved this failure did not emit a parsable nextest `FAIL`/`LEAK` line, so the next follow-up extends the annotations to the last 80 log lines and requests explicit final failure output from nextest. |
 | `495ef3f76` | Expose nextest failure tail in CI | failed | Run `23083992418` failed in both Windows `Tests` jobs. The new annotations identified `codex::tests::run_user_shell_command_does_not_set_reference_context_item` timing out on Windows x64 and `all::suite::fuzzy_file_search::test_fuzzy_file_search_session_multiple_query_updates_work` timing out during app-server `initialize` on Windows arm64. |
 | `d017d0fc3` | Stabilize Windows shell and fuzzy search tests | failed | Run `23084639316` fixed the original Windows-targeted failures, but introduced a new failure in `Tests — ubuntu-24.04 - x86_64-unknown-linux-gnu`: `all::suite::fuzzy_file_search::test_fuzzy_file_search_session_update_works_without_waiting_for_start_response`. The in-process harness used spawned `sender.request(...)` tasks, which made request submission order nondeterministic and let `sessionUpdate` race ahead of `sessionStart`. `Bazel (experimental)` also failed on macOS in the same patch window, and the still-running Windows jobs were superseded by the next follow-up commit. |
+| `4195e7e80` | Preserve in-process fuzzy search request ordering | failed | Run `23084952538` proved the Linux ordering fix was necessary, but the follow-up widened the `app-server` public API with methods that returned a private type alias. `Lint/Build` failed on Linux and macOS before the remaining `Tests` jobs finished, so the next follow-up narrows the public signatures back to concrete types and reuses the same request-order behavior. |
diff --git a/codex-rs/app-server/src/in_process.rs b/codex-rs/app-server/src/in_process.rs
index 7c83c0065c..f48eb1fdaf 100644
--- a/codex-rs/app-server/src/in_process.rs
+++ b/codex-rs/app-server/src/in_process.rs
@@ -100,7 +100,7 @@ pub struct PendingInProcessRequest {
 }
 
 impl PendingInProcessRequest {
-    pub async fn recv(self) -> IoResult<PendingClientRequestResponse> {
+    pub async fn recv(self) -> IoResult<std::result::Result<Result, JSONRPCErrorError>> {
         self.response_rx.await.map_err(|err| {
             IoError::new(
                 ErrorKind::BrokenPipe,
@@ -225,7 +225,10 @@ impl InProcessClientSender {
         Ok(PendingInProcessRequest { response_rx })
     }
 
-    pub async fn request(&self, request: ClientRequest) -> IoResult<PendingClientRequestResponse> {
+    pub async fn request(
+        &self,
+        request: ClientRequest,
+    ) -> IoResult<std::result::Result<Result, JSONRPCErrorError>> {
         self.start_request(request)?.recv().await
     }
 
@@ -290,7 +293,10 @@ impl InProcessClientHandle {
     /// request IDs unique among concurrent requests; reusing an in-flight ID
     /// produces an `INVALID_REQUEST` response and can make request routing
     /// ambiguous in the caller.
-    pub async fn request(&self, request: ClientRequest) -> IoResult<PendingClientRequestResponse> {
+    pub async fn request(
+        &self,
+        request: ClientRequest,
+    ) -> IoResult<std::result::Result<Result, JSONRPCErrorError>> {
         self.client.request(request).await
     }