Repository navigation
[Operator]: Fresh consumer install and handoff evidence boundary #158
Description
Harness, OS, and Node version
macOS; Node v22.23.2; Codex CLI 0.153.4 was installed and its probe succeeded. I also ran a minimal custom loop that imported only public @fyaic/threadmesh entry points. I am independent of the ThreadMesh maintainer organization.
Installation path
One-command GitHub package:
npm install github:fyaic/threadmesh#v0.1.0-alpha.1
The fresh consumer install completed successfully in about 5 minutes and npm reported 0 vulnerabilities. The no-model API preview then completed successfully in about 3.3 seconds.
Time to first useful result, or where I stopped
The public-API custom harness produced a useful result immediately after installation. A real Codex launcher attempt stopped about 14 seconds after launch: Codex returned a usage-limit error before a model turn began. No live model collaboration or Codex-authenticated business edit is claimed.
What does ThreadMesh do?
ThreadMesh connects explicitly joined local workstreams so a sender can discover a bounded peer goal and queue one expiring advisory. The receiver reads that advisory and makes a separate disposition. ThreadMesh does not perform the receiver's business work, grant authority, or turn acceptance into proof of completion.
Five evidence questions
- Who was authorized to initiate it? The two workstreams were explicitly joined by the same local workspace owner. This establishes the local admission boundary used by the alpha; it is not a multi-tenant security result.
- Which task and policy allowed it? Discovery returned only the joined client goal. Sending before discovery failed closed with
threadmesh_discover_before_send; after discovery, one advisory was queued to that bounded peer. A second send in the same harness turn failed closed with the same guard. - What receiver disposition occurred? The message appeared in the receiver inbox as
untrusted-peer-advice, withdelivery=durably-receivedanddecision=pending. The receiver then explicitly accepted it. - What evidence verified the result? The final receipt remained
delivery=durably-received,decision=accepted,outcome=not-observed. The client business file did not change before acceptance; the custom harness wrote it only in a separate post-acceptance step. Therefore the run verifies delivery and disposition, not business completion. - What cleanup remains? The custom scenario removed its disposable workspace and verified that it no longer existed. No credentials, transcripts, task/session IDs, or local paths are included here.
First confusing or failed step
The GitHub install was quiet for several minutes and encountered a transient ECONNRESET retry before completing. The first real-harness attempt then failed at the Codex provider usage limit before model work. Both are environment/setup evidence, not ThreadMesh success.
I did not test the receiver-already-running case in this short scenario.
Would I use it?
Yes, for a narrow same-owner local workflow where peer advice is useful and must remain visibly advisory—for example, an API contract change informing a dependent client. I would keep the acceptance/completion distinction explicit and would not yet treat this run as evidence that the new Codex model path works, because that path was blocked before a model turn.
Evidence checks
- I found why delivery alone did not unlock the dependent task.
- I found what happened when the receiver was already running; not tested in this run.
- The disposable custom harness reported cleanup complete.
- I am independent of the ThreadMesh maintainer organization.
- I removed credentials, transcripts, IDs, and local paths.
Activity
veil-chow-fyaic commentedon Sep 7, 2026
Thank you, Andrei — and apologies for the delayed acknowledgement. You completed the independent check and notified us in #79; we should have responded sooner and updated our status instead of continuing to say that no independent report existed.
This establishes an independent fresh-consumer install and public-API harness check, including discovery-before-send, the one-send guard, durable receipt, explicit acceptance, and cleanup. It does not establish autonomous model-to-model collaboration, business completion by an agent, or delivery to an already-running receiver. Your separation of these is important.
The roughly five-minute install with little visible progress is a first-use problem we need to own, even where a transient network error contributes. Likewise, detecting an installed Codex binary is not evidence that a model turn can run. The usage-limit failure should be understandable before users spend more time assembling a demo.
Our next product priorities are:
These are delivery targets, not claims that the current alpha already provides that experience. We also have not established the native desktop-session experience.
No need to retry against an exhausted quota or provide private transcripts. We will keep this issue open for the onboarding follow-up and acknowledge this report in #79; the remaining live and busy-receiver checks are still open. Thank you for giving us a concrete first-use failure to fix, not just another internal benchmark.
veil-chow-fyaic commentedon Sep 7, 2026
Concrete follow-up: v0.1.0-alpha.2 is now published, and #163 has merged with CI passing.
The release provides a prepacked, version-pinned install (avoiding npm's Git-checkout preparation) and
threadmesh try preferences --live: it prepares the example and starts two Pi sessions in one terminal. Users no longer have to write a custom harness or supply an application fixture to try the real path. Installation guidance enables visible npm progress; runtime stages, provider errors, timeout and cancellation are explicit.We verified one real copy case and one API case from an independently installed package. Both had model-selected contact, continuation of the same receiver, and its own business-checked file change. These are maintainer runs, not independent adoption or a reliability score. The public release URL was also installed in a fresh consumer and its command checked. Evidence and limitations.
This remains a Pi-first developer entry using an already configured model and its normal quota. It does not resolve existing native Codex desktop attachment, an exhausted Codex account, or the busy-receiver case. You should not have to install another agent or buy another subscription just to validate our change.
Keeping this issue open for those remaining first-use gaps. Thank you again: your report directly changed what we shipped.
hlinor-systems commentedon Sep 7, 2026
Thanks for the clear acknowledgement and for separating the observed guarantees from the remaining product claims.
That matches the intent of the report. The most useful next step seems to be the self-contained two-session example with visible install/run and quota status, plus evidence that the receiving session changes the intended artifact after acceptance.
I’ll leave the live-receiver and native desktop-session checks for a separate run when a usable account path is available.
veil-chow-fyaic commentedon Sep 7, 2026
Thank you, Andrei. We followed your three concrete priorities, with Codex users first this time.
v0.1.0-alpha.3 now defaults to a self-contained Codex → Codex example using the existing login and model.
threadmesh try --liveprepares the sample and runs both sessions; no custom harness, application fixture, Pi installation or second subscription is required. The install/run guide makes installation progress visible and explains quota, runtime and timeout failures. We do not bypass exhausted quota or silently switch products.The installed-package default run completed in 272.604 seconds within its 300-second cap. The original receiver made its own checked edit, preserving the earlier button decision and paid price. We retained the failed attempts alongside the passing evidence. This is one maintainer result, not a reliability rate or your independent live pass.
Separately, one controlled desktop pair with completed prior context produced model-selected native advice and the original receiver's own edit; the actual exchange and diff are public. Codex supplies the native transport and continuation; our skill adds workflow guidance, with no measured advantage over native-only use yet. The busy/stop checks are not proof of race-free sending.
We also tried the simpler public-link/title-based readiness entry. That check is not accepted. Read-only diagnostic update: the desktop task-reading tool initially exposed no current-turn items, but the official App Server read recovered both original results: each failed on
list_threads(limit: 100), above the host's maximum of 50. The recovered records contain no outgoing peer sends or file edits. We corrected the source workflow's limit; a subsequent valid bounded inventory still did not contain the selected pair, so successful title resolution and desktop onboarding remain unproven. The attempt and diagnosis retain both observations; we did not rerun the models.Keeping this issue open for the remaining onboarding gaps. No need to retry with exhausted quota or share private transcripts. Your report changed the first-use path and what we require before calling a handoff useful.
veil-chow-fyaic commentedon Sep 8, 2026
One concrete native-desktop follow-up since the failed title-based readiness check: we now have a completed public workflow + chat-link run in the original two validation tasks.
The English entry / 中文入口 uses Codex's documented Copy chat deep link command plus a limited shared topic. It does not require Node/MCP setup, a shared worktree, an internal-ID search or a global task inventory.
Both tasks confirmed setup without peer messages or business edits. An ordinary product-change request to A then produced one model-chosen native message; original B updated its own copy, preserving the earlier signup button and paid price. The business handoff took about 61 seconds; setup took about 137/141 seconds in parallel and is reported separately. Both tasks were stopped afterward. Actual steps, receiver diff, timings and retained-evidence hashes.
This is a maintainer link-input test: the manager supplied official-format links through native tools, not an independently verified keyboard/GUI onboarding run. Codex provides the transport and continuation; our optional skill provides collaboration guidance, with incremental benefit still unmeasured. This is a source-workflow update, not a replacement alpha.3 package or a quota workaround.
The earlier discovery failure is also explained and retained: these agent-created test tasks had empty previews, which the runtime excluded from normal lists. Repeated manager messages were not going to fix that sample. Keeping this issue open for actual-user onboarding; no need to retry while your account path is unavailable.
Historical usability experiment, September 8: the bilingual setup-text helper was deployed and checked in a real browser, but has since been removed from source and hosting in #177. It did not meet the install-and-use product requirement. The following describes that earlier experiment, not an available website. It generates the two setups from copied chat links and a limited topic; it neither reads chats nor uploads inputs. You still paste/send each setup yourself and wait for both confirmations—this is not an automatic connection.
We also used its exact generated prompts in the original validation pair for an API/client case. An ordinary API change request to A led to A's chosen native send; original B updated its own client and five passing tests, preserving the earlier 3000 ms timeout and cursor-handling decisions. Business handoff was about 70 seconds; setup was about 31/23 seconds separately. Both tasks were stopped. Actual helper screenshot, checks and case evidence. This was local client adaptation, not an HTTP-service test or independent GUI onboarding. The generated text was dispatched through native tools by the maintainer, not automatically sent by the browser. These results improve the available entry without changing the limits above or asking you to retry an unavailable account.