You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PR #52 added first-class Codex thread inspection, send, and wait commands within one LastCode environment. A Codex thread running in one environment still cannot discover or address a thread owned by another environment.
The concrete use case is a small personal setup with two machines: Codex on Airy should be able to find, inspect, message, and wait for a thread running on htulo, and vice versa. Today this falls back to ad hoc SSH and direct remote SQLite inspection.
Desired outcome
Discover configured LastCode environments and their reachable threads.
Resolve a thread by explicit environment plus thread ID, with a convenient unambiguous lookup path for user-directed queries.
Support the existing read, send, and wait operations across environments.
Reuse authenticated LastCode environment transport and scoped credentials rather than reading a remote database directly.
Preserve environment identity in command output so local and remote results cannot be confused.
Keep the design appropriate for a single user with two machines and usually fewer than ten concurrent threads.
Example user-directed flows:
What is THREAD_ID up to?
Ask THREAD_ID some question.
Tell THREAD_ID to do something.
Do this, and when finished tell THREAD_ID to do that.
Scope constraints
Tracking only; do not implement yet.
Optimize for the existing two-environment personal deployment, not a general fleet or multi-tenant message bus.
User-initiated workflows are sufficient initially; autonomous agent-created workflow graphs can wait.
Avoid broad retry, reconciliation, or routing machinery unless a concrete failure in this deployment requires it.
MCP may expose the capability, but should not force an unnecessary bridge if LastCode can directly serve the same authenticated environment operations.
Design questions for later
Should remote environment discovery come from configured LastCode connections, MCP configuration, or a small explicit host registry?
Should the CLI extend lastcode-thread with an environment selector, or add a separate environment-aware entry point?
What is the smallest addressing syntax that remains unambiguous when thread IDs or prefixes overlap across environments?
Dependency
Build on the local-environment primitives merged in PR #52. This issue intentionally defers implementation until we choose the transport and addressing model.
Problem
PR #52 added first-class Codex thread inspection, send, and wait commands within one LastCode environment. A Codex thread running in one environment still cannot discover or address a thread owned by another environment.
The concrete use case is a small personal setup with two machines: Codex on Airy should be able to find, inspect, message, and wait for a thread running on htulo, and vice versa. Today this falls back to ad hoc SSH and direct remote SQLite inspection.
Desired outcome
Example user-directed flows:
Scope constraints
Design questions for later
lastcode-threadwith an environment selector, or add a separate environment-aware entry point?Dependency
Build on the local-environment primitives merged in PR #52. This issue intentionally defers implementation until we choose the transport and addressing model.