Possible repo/task context misrouting across threads with unresolved remote task ownership

Summary

I hit what appears to be a repo/thread context routing failure while using Codex Desktop across multiple local repos on the same machine.

The intended implementation thread was bound to a repo A workspace, but work later appeared to continue in a different project context. Local forensics show strong evidence of task/runtime repo misbinding or stale thread/runtime state, though I could not fully resolve one remote task id from local artifacts.

This issue is not a complaint about bad code quality. It is a context integrity issue: if real, it can cause edits in the wrong repository.

Expected behavior

A thread or task that is started in repo A should remain bound to repo A unless there is an explicit, visible repo/workspace switch.

If Codex cannot resolve repo ownership for a task, it should fail closed and avoid making code changes in another repo.

Actual behavior

Observed behavior from local artifacts:

• Original thread was clearly in repo A
• A separate/wrong project context involving repo B was later observed by the user
• Desktop logs contain repeated warnings of the form:
• No owner repo found for remote task taskId=task_e_...
• The exact remote task id the user saw was:
• task_e_69c8a440a5848331bd08752c97b0d563
• I could not map that exact task_e_... id to a local stored session file, so I am reporting that uncertainty explicitly

Evidence

Original intended thread

Stored local session:

• 019d35aa-5914-77b0-878d-ca7cf2ce4a9e

Local session metadata shows:

• cwd: /path/to/repo-A
• repo remote: https://github.com/repo A.git
• branch: main

The session log also includes an explicit prior correction from the user:

• "this thread belongs to a different environment - repo A, not repo C or repo B"

And the later repo A session itself stayed repo-A-specific:

• repo A file paths in edits
• repo A xcodebuild invocation
• repo-A-specific final summary

Wrong-project evidence found locally

I found a separate same-day session that edited repo B files:

• repo paths under /path/to/repo-B/...
• examples:
• repo-B.xcodeproj/project.pbxproj
• Sources/App/MainAppView.swift
• Sources/Views/PaywallView.swift
• .gitignore
• repo-B.xcconfig.example

I cannot prove from local artifacts alone that this exact repo B session is the same as task_e_69c8a440a5848331bd08752c97b0d563.

Desktop log warnings

Local desktop logs repeatedly show unresolved remote task ownership warnings, for example:

• No owner repo found for remote task taskId=task_e_6893747485848331a0686f85db2ec5c3
• No owner repo found for remote task taskId=task_e_689374747df0833192f7f5e5551a072d
• No owner repo found for remote task taskId=task_e_68937475717c8331b89ce1b5758986e6

These came from:

• desktop log directory for 2026-03-28...

I am including them because they look directly relevant to repo/task routing integrity.

Why I think this may be a Codex issue

Prompt ambiguity does not look like the primary cause here.

The intended repo A thread had explicit anti-ambiguity instructions and repo identity markers. The stronger signals point to one of:

• workspace/repo misbinding
• thread context leakage
• runtime/task ownership failure
• stale desktop runtime state

I also saw another same-day thread conclude that the local desktop runtime needed a full restart to pick up updated MCP/runtime state. That is not proof of the repo switch, but it does point to stale runtime state as a possible contributing factor.

Impact

Potential unintended edits in the wrong repository.

Even if the actual code changes are recoverable, the integrity failure is high-risk because the user may reasonably trust the active thread/repo binding.

Suggested product behavior

If repo ownership for a thread/task is unknown:

• block write operations
• surface a visible warning in the UI
• require explicit repo confirmation before continuing
• expose task -> repo binding more clearly for forensic/debugging purposes

Repro status

Not reliably reproducible from local artifacts alone.

This is currently an incident report with concrete local evidence, not a deterministic reproduction.

Environment

• Codex Desktop
• multiple local repos open/saved on same machine
• repos involved in local evidence:
• repo A
• repo B
• also another local workspace present in saved workspace roots
• date of observed incident: 2026-03-28 local time

Uncertainty / limits

What I could not verify from local artifacts:

• the exact local session mapping for task_e_69c8a440a5848331bd08752c97b0d563
• whether the wrong-project repo B edits I found are exactly the same task the user observed, versus a nearby same-day context incident

Still, the combination of:

• explicit intended repo binding,
• wrong-project evidence,
• and repeated No owner repo found for remote task warnings

seems strong enough to warrant investigation.