APX

APX tracks four control states per browser tab: idle, agent control, temporary handoff, and user control.

APX developers believe a good handoff should have four properties: the human can take over the tab without negotiating with the agent; the agent's reads and operations stop; sensitive input does not enter chat or tool output; and returning control is explicit, with the agent not guessing when work can resume.

In its regular tool flow, APX requires that: clicks reference elements in the latest accessibility snapshot; after reading untrusted page content, typing as an external action requires confirmation; browser text is marked as untrusted; and the agent is guided to check the new page state before claiming a form was submitted or a message was sent.

APX assigns each agent its own browser profile and checks ownership before operations; an agent cannot drive tabs assigned to other agents, and if another agent is controlling a tab, APX rejects the request rather than letting two running instances manipulate the same page simultaneously.

APX provides a path for requesting user approval to copy cookies for a specific domain into the APX browser profile; this operation can only be performed by a human, and at runtime the origin name and number of domains can be checked, but cookie values remain on the desktop side.

Under the browser_handoff mechanism, the agent can receive only one of two answers: the owner has completed it (with the current URL), or the owner did not complete it within the time limit (the agent stops); the agent does not receive passwords, verification codes, or a stream of human interaction.

The APX browser tool provides a browser_handoff action for login, password, 2FA or CAPTCHA scenarios, recording a brief reason, marking the browser card as in handoff state, and waiting up to five minutes for the owner to complete the action.

APX's control blocking takes effect before the page is read, not merely before the click.

When the user clicks "Take Control", the APX desktop host changes that tab's state to user, after which any read or operation attempt by the agent fails and returns paused_by_user.

APX's 'not run' record only indicates that APX did not receive a completed tool result for that turn; it does not claim that the action failed in the external world.

APC keeps project context portable, and APX keeps execution history accountable.

When a turn that depends on tools is interrupted, the three questions of 'was a tool requested', 'did APX receive a matching result' and 'what check is safe before continuing' should be handled separately, and only the second question can get a definite answer from the repaired history.

APX's chat history, tool call records, sessions and interruption markers are local execution state and are not part of a portable project contract.

APX's runtime history repair logic starts from real user entries, ignores orphaned tool results, checks whether each assistant tool call has a matching result, and closes unanswered calls with an explicit record when a new non-tool entry appears or the history ends.

When repairing chat history, APX follows one rule: an interrupted tool call must have an explicit outcome in the conversation history, recorded as 'not run: the turn was interrupted'.

The apx messages tail command can use the --project flag to specify a project, for example apx messages tail --project storefront.

APX's conversations, sessions, task logs, and private runtime state are kept locally in the ~/.apx/ directory.

Project names are short yet efficient context, avoiding reliance on old topics that may no longer be relevant.

Explicitly naming the project is regarded as the lowest-cost means of correcting context drift, because it provides an observable, reviewable boundary signal at every turn.

The apx agent list command can use the --project flag to specify a project, for example apx agent list --project data-pipeline.