Skip to content

Qualify the execution host, Mac connection and mobile recovery route #2

Closed

Description

@gustavonline

Outcome

A selected Linux host runs T3 and native workers independently of the operator client. The owner can inspect work and answer a real decision from the Mac and chosen phone route. Configuration and live evidence must be distinguishable.

Scope and boundaries

Use a pinned T3 release and the selected Codex/Claude profiles. For a shared personal host, prefer a VM with an unprivileged guest and no implicit personal-home, browser, SSH-agent or socket sharing. A dedicated host may use a separately qualified OS user. Separate provider profiles do not create filesystem isolation. Preserve the earlier Factory installation/history until cutover is accepted.

Required proof

  • Inspect host ownership, actual execution identities, versions, power/network and existing work; choose the boundary before changing a running service.
  • Authenticate the intended native profiles using provider login links; verify actual discovery and reference loading of the selected Factory skills in both harnesses. Keep credentials private.
  • Verify the native background service, boot/logout behavior, private access route and least necessary effective permissions.
  • Run harmless work, close the Mac client, reconnect, change network and perform a controlled host/service restart. Record interruption truthfully and reconcile without duplicate work.
  • Exercise one actual phone question/answer. T3's phone route is not the existing Codex/ChatGPT conversation; background push requires its selected supported connection.
  • Show missing login/provider, denied permission and stale/disconnected state without inventing success. Read quota/reset information without exhausting the subscription.
  • Record backup/restore and version recovery; binary downgrade alone is not database recovery.

Source research on T3 0.0.45 and a newer nightly is in the decision record. Native version selection and actual readback govern this pilot. No new Factory relay, VPN, daemon or VM manager. Admission to this setup backlog does not resolve an unchosen host migration or identity boundary.

Prior context

#39, #135, #137, #138. These discussions are retained as evidence; their old runtime/UI implementation scope is superseded.

Selected-route acceptance — 10 October 2026

The selected host/Mac/iPhone route is qualified by the dated v0.1.8 record and the native/owner readback in this issue: Mac independence/reconnect, deliberate service interruption and physical reboot after disk unlock, an actual locked-phone notification/question/answer, mobile-data exchange, powered closed-lid exchange and desktop-logout exchange.

This does not promise automatic completion after interruption, battery/suspend recovery, host-network outage recovery, every approval type or autonomous operation. The remaining provider/worker permission friction is #7; application adoption is #4. No new broad permission grant or automatic updater was introduced to complete these tests.

Activity

  1. gustavonline commented on Oct 7, 2026

    @gustavonline
    ContributorAuthor

    Host setup and both native desktop clients have live evidence; this issue remains open for mobile, physical-operation and remaining recovery observations.

    Original fixture baseline: Factory method v0.1.0 (fe56aae), T3 v0.0.45, Codex CLI 0.160.0 and Claude Code 2.1.289. The existing Mac app also reports T3 v0.0.45. The previous Factory installation and history remain available; this is not a cutover.

    Observed on the execution host:

    • A native systemd user service runs under a separate unprivileged OS account. It is enabled with lingering and binds only to loopback. Private SSH access from the existing operator client works. The worker has no sudo, private-home or Docker-socket access, and no forwarded SSH agent.
    • Codex implemented a disposable fixture and passed four tests; Claude Opus 5.5 reviewed it in a separate native thread and reran the tests. Project-scoped Factory discovery was observed in both harnesses, including new worktrees and Agent Ops reference loading. The installed skill files match the retained staging manifests.
    • Closing the browser's SSH route while Codex worked did not stop the host task. Reconnection showed the completed result. A controlled T3 restart during another running command instead produced a visible failed/interrupted session; a follow-up reconciled existing files without replaying the operation.
    • Missing authentication and a missing provider binary produced distinct native errors. Both temporary configurations were removed. Unauthenticated and invalid-token WebSocket requests were rejected. Native quota/reset readings were displayed without quota exhaustion or paid overage.
    • A cold archive was actually restored, including T3 state, native provider state, projects and worktrees. Database integrity passed; both projects, four threads and six existing turn records matched the pre-restore snapshot. The four fixture tests passed again. The prior directories and archive remain private. This tests same-version recovery, not a future database downgrade or off-host disaster recovery.

    A separate native Opus 5.5 reviewer checked the versions, service, permissions, skill hashes and worktree bindings. It found ambiguous recovery-document references and missing retained readback; those were corrected and rechecked. Its final recommendation accepts this limited local software setup, with the following qualification gaps still open.

    Limits and next observations:

    • This is an OS-account boundary on a shared host, not a VM or network isolation, and the lead and workers share provider profiles. Only nonsensitive software fixtures were qualified. Stronger project/Defence boundaries remain separate work.
    • Existing dedicated Factory logins were deliberately migrated to the execution account; they are not independent new OAuth sessions. No personal provider history or GitHub/deployment credentials were copied. A real repository's GitHub access remains a separate setup choice.
    • The native Mac app uses its saved SSH environment and the native desktop app on the execution host uses same-host pairing to the same independent service. Both were restarted and verified Connected with Local environment off and the same history. A task submitted from the Mac completed on the host after the Mac app fully exited; service process identity stayed unchanged. The host desktop also verified the selected Linux icon, pinned AgentOps thread in Factory and removal of the canceled Kanban action. Temporary redeemed pairing links were removed. Physical reboot/network and phone proof remain separate.
    • Physical reboot, physical lid behavior and a real network change remain untested. AC lid handling and boot/logout configuration were inspected and set; configuration is not physical proof.
    • A real phone question/answer and its chosen native notification route remain open. No custom relay, scheduler or public listener was introduced. Automatic continuation after server restart remains off.

    The active Factory source checkout is now on method v0.1.1 (84729f1, PR #11). Package validation and all seven tests passed again on the execution host. It adds the reusable client/AgentOps guide and diagram. Prior trial-project skill copies and their v0.1.0 evidence are retained; the persistent AgentOps startup turns loaded the original canonical sources, so this source update is not a claim of a new native turn or discovery.

    Private screenshots, exact paths/identities, configuration, adoption manifests and the recovery procedure are retained in the installation record, outside this public repository. The setup fixtures do not close the Agent Ops or real application delivery pilots.

  2. gustavonline commented on Oct 9, 2026

    @gustavonline
    ContributorAuthor

    9 October update: the execution service and both desktop clients now run official T3 0.0.46-nightly.20261009.2861. Factory 0.1.2, delivered through PR14, documents the qualified setup and recovery limits.

    The service retains the separate unprivileged execution account, loopback binding and existing private access routes. Both clients showed Connected to that service. No provider access or listener was broadened.

    The native V1→V2 migration preserved all 98 user/assistant messages, nine thread shells, three AgentOps pins and four archived trial chats; both databases pass integrity checks. V1 tool/reasoning history remains in the retained old database and private backup. The migration starts fresh provider sessions. All 44 selected installed skill files match Factory 0.1.2.

    The legacy repository is publicly archived and its identified runtime remains disabled under the owner's explicit retirement instruction. Recovery copies and histories remain available. This is not proof of the remaining physical-operation or phone checks.

    Still open: physical reboot/lid/network recovery and a real phone decision. Nightly requires the compatible mobile beta; the stable store app is not qualified against this server. The dated qualification record distinguishes these gaps from observed results.

  3. gustavonline commented on Oct 9, 2026

    @gustavonline
    ContributorAuthor

    9 October: T3 Connect is working between the execution host and Mac; the owner confirms Factory and pinned AgentOps are visible on the iPhone beta.

    • The existing host service is linked with activity publishing and the native managed relay. It still listens on loopback. This external access route was explicitly owner-approved.
    • The Mac uses Connect, with its existing SSH route retained as fallback. A real task continued and launched its worker while the Mac app was fully quit; reopening restored the same conversation. The host service process did not restart.
    • An idle service restart completed after all runs and known background work settled. This does not prove restart during active work or physical reboot/lid/network recovery.

    Factory v0.1.3, from PR15, includes the concrete Connect setup and the bounded observations. All 44 selected installed skill files match this release; backups are retained privately.

    Still open: a real phone message/decision and background notification that opens its response, plus the physical-host/network checks. Visibility alone does not satisfy these checks. No application pilot was started; the owner's Factory-first priority remains in force.

  4. gustavonline commented on Oct 9, 2026

    @gustavonline
    ContributorAuthor

    Progress on 2026-10-09, with method changes in #17:

    • Physical reboot passed after owner disk unlock: a new boot identity, automatically active user service, preserved message content and adopted skills; native AgentOps readback completed. Mac first used SSH fallback; returning to Connect required a manual reconnect.
    • T3 server now matches Nightly 2873. Native Codex 0.162.0 and Claude 2.1.295 replaced copied root-owned launcher paths. Claude doctor confirms native auto-updates enabled. No worker administrator grant was added.
    • Codex's actual T3 Auto turn allowed a disposable workspace write and denied an outside write with an OS read-only-filesystem error; cleanup left Git clean. Claude's terminal probe passed, but its T3 probe is quota-paused with native Resume at reset selected. This is not a completed Claude integration check.
    • Two obsolete projects and their four archived chats were removed through native T3 after explicit owner approval; source folders and active Factory remained. The exact subsequently requested backup was deleted.

    Still open: real phone question/notification/response, remaining physical network/lid/logout cases, Claude's resumed T3 probe, and a qualified unattended system/server maintenance route. Omarchy update checks exist; automatic OS installation is not enabled. The bundled checklist items remain open rather than treating partial evidence as completion.

    Delivery readback: #17 and #18 are merged; v0.1.5 is published and the host source matches main/tag. All 44 installed files in the two selected skill scopes match the reviewed stage. Fresh Codex CLI discovery found all seven selected skills and read the revised installed instructions. The documentation-only 0.1.5 release leaves those skills at revision 0.1.4. Claude/T3 reload is still pending; its bounded auto-resume choice is persisted on the server for the observed reset, not a new recurring Factory scheduler.

  5. gustavonline commented on Oct 9, 2026

    @gustavonline
    ContributorAuthor

    9 October — correction to the earlier pending Claude status: v0.1.6 is published and installed on the selected execution host. All 44 selected installed files match the reviewed release. Native Codex and Claude sessions explicitly read the six revised files in each provider scope with zero mismatches.

    Opus 5.5 High completed the actual T3 sandbox write/refusal check: the disposable workspace write succeeded, the outside write was refused, and cleanup was verified. The earlier quota-paused Claude trial is no longer outstanding; its old auto-resume remains disabled. This does not establish general read/network/MCP isolation or separate role credentials under the shared execution account.

    This evening the same host service and AgentOps also passed the bounded continuation/retry check recorded in #3. No service restart or access expansion was needed.

    Still deferred: real phone notification/question/response, physical network/lid/logout observations and any separately accepted unattended maintenance qualification. Existing OS update checks are not unattended OS installation. These remaining checks keep this issue open; no new updater or schedule was enabled.

  6. gustavonline commented on Oct 9, 2026

    @gustavonline
    ContributorAuthor

    9 October — native file permissions qualified; v0.1.7 delivered.

    PR #20 is merged and v0.1.7 is published. Host main/tag match the reviewed tree. All 44 selected installed files match; Codex and Claude explicitly reloaded the four changed sources in each provider scope.

    The earlier successful Bash probe did not cover Claude’s native file tools. Auto allowed outside Read/Edit/Write. The selected user-profile read restriction blocked Read but not Edit/Write; with the same restriction and Auto-accept edits, the two outside write requests were individually declined and the fixtures stayed unchanged. Three check commands and one installed-skill read needed individual approval. This is assisted operation under shared credentials, not three isolated roles or unattended operation. The dated qualification retains the failures and limits.

    Still open by owner deferral: actual phone question/notification/response and physical network/lid/logout observations. Native update checks and interactive maintenance remain distinct from unattended OS/server installation; no updater or new schedule was enabled.

  7. gustavonline commented on Oct 10, 2026

    @gustavonline
    ContributorAuthor

    Live qualification, 2026-10-10, T3 Nightly 2873 and the selected iPhone beta via T3 Connect:

    • Owner received a native AgentOps question as a notification on the locked/backgrounded phone, answered in T3, and native readback confirmed the resolved answer and acknowledgment.
    • Owner disabled iPhone Wi-Fi, sent a message over mobile data and received the reply; the native record identifies the mobile sender.
    • With the host on external power, physical lid-closed state and the same active service/boot were observed while a mobile exchange completed.
    • After desktop logout, only the desktop user's lingering manager remained; the execution service kept its process/start time and a mobile exchange completed before login.

    Private native readbacks are retained. The bounded results and limits are included in #22. These checks do not establish host-network-outage recovery, battery/suspend behavior or every approval/notification type. Existing Mac independence, controlled service restart and encrypted-host reboot proof remain dated 9 October. No new access, relay or scheduler was added.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    foundationHost, repository and skill preparationqualificationObserved proof of a capability

    Type

    No type

    Projects

    • Status
      In progress

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions