Dot continuity: access blockers, missed context, and a Codex authorization handshake

I have used my current dot for a little over a month. Previously working access repeatedly becomes a blocker, and its recall of ongoing work feels less reliable than regular ChatGPT chat and codex.

With ticketing/helpdesk work, I have had to remind it about tickets, links, and planning decisions already discussed. I also have to explain previously working access routes again. From my side, sessions seem to disappear, but it is often unclear whether the actual cause is expired authentication, a different environment, missing tools, or failure to recover the documented workflow.

My suggestion is a supported authorization handshake between dot and local Codex. Once the user has authorized the connection and task scope, delegated work should carry verifiable authorization and use the appropriate, already-approved Codex access level without repeatedly requesting the same permission.

Actions, results, and concerns should remain transparent and auditable. Routine concerns should be reported rather than automatically stopping work already authorized within scope. New scope or materially different risk should still receive the appropriate checks, and authorization should be revocable. This is not a request to bypass security.

Alongside that, dot needs more reliable retrieval of saved skills, meeting notes, ticket links, and unfinished commitments, plus a preflight that distinguishes authentication problems from missing tools or the wrong environment.

The goal is continuity: I should not have to manage the same setup and context-recovery problems every time I delegate work. Are these known limitations, and is there a recommended supported approach?

Please also preserve authorized sessions for longer and avoid unnecessary resets, so working access remains available across tasks. The loss of access feels recurring, but I do not know the interval and cannot confirm a weekly pattern. When a session must expire or be reset, please make the reason clear and provide a supported recovery path.

Disclaimer: I’m only highlighting the user pain points here.