From Chat to Programmable Execution: Reverse Engineering ChatGPT Desktop

An evidence-bounded reconstruction of Chat, Work and Codex; their authorization and integrity paths; and a completed client-executed tool loop on the Chat surface.

I did not begin this research because I wanted a model to call one function. Tool calling already exists across the OpenAI product family. I began because three experiences presented inside one desktop application appeared to divide conversation, delegated work and usage accounting in ways that the interface did not fully explain.

The question was architectural: if the Chat surface could participate in a client-executed tool loop, could a conversational product boundary also become a programmable execution boundary?

Under the conditions I studied, Chat remained available while the separate Codex allowance was exhausted. I then completed two interactions in which the model requested a custom capability, the desktop client participated in its local execution, the result was written back into the conversation, and the model continued from that result. That sequence is the demonstrated finding.

The larger possibility is an OpenAI-compatible adapter around that behavior. Such an adapter could translate a familiar API contract into interactions coordinated through ChatGPT Desktop. I did not build or operate that service. I stopped after the custom-tool loop because sustained operation, enforcement behavior and quota substitution are different experiments. This report documents the surface that makes the possibility worth reviewing; it does not claim that the possibility was converted into a durable service.

That stopping point is part of the result. It leaves a clean boundary between what I observed and what an attacker, product engineer or security reviewer might infer from it.

Figure 1. The relevant product surfaces, transports and accounting observations. The green findings were observed in the historical environment; the red statement marks what the experiment did not measure.

1. One application, three execution semantics

The application I examined combined a native macOS shell, an Electron-based interface, an embedded Codex app-server and several remote services. The visible tabs were therefore interfaces over different execution arrangements rather than cosmetic modes over one uniform request path.

The fixed vocabulary matters:

The distinction is visible in behavior. Work exposes a handoff capability and can create a local task. Codex operates directly through the app-server's thread and tool protocol. Chat uses a conversation tree and can receive client-declared capability descriptions. The same desktop application coordinates all three, but shared presentation does not imply shared authority or accounting.

This is why “the model called a tool” is an insufficient description of the result. A normal tool call in Codex would say little about Chat. The relevant observation is that the client-declared capability loop completed on the Chat surface whose availability was observed separately from the exhausted Codex allowance.

No financial figure follows from two calls. What follows is a control question: if interactive inference can be externally coordinated into useful local execution, does the product's accounting model follow the work being performed, or only the surface through which the work entered?

2. Authorization is necessary, but it is not the entire client model

OAuth is a documented part of the Codex ecosystem and belongs in the reconstruction. Its role is to establish delegated account authorization and maintain that authorization over time. The desktop application also carries account, installation and device context across more than one surface.

The research separated six responsibilities that are often collapsed into “authentication”:

This separation prevented a recurring analytical error: treating a valid account token as proof that the rest of the request was equivalent to the official client. It is not. Authorization identifies an authority relationship. Client integrity, request freshness, application context and conversation continuity remain separate dimensions.

The desktop also used a link-session mechanism for authenticated webviews. That path explained how a bearer-authenticated desktop session could establish a browser-scoped view without making ordinary Chat traffic a cookie-driven browser session. The distinction becomes important when comparing third-party projects: a real browser session, an OAuth-backed Codex client and the desktop conversation path may all involve the same account while presenting different state and integrity characteristics.

The observed OAuth lifecycle

At the level relevant to this report, the desktop authorization lifecycle followed the public-client pattern used by Codex: an authorization request protected with PKCE, a callback that completed the code exchange, and a refresh lifecycle that renewed account authority before expiry. The embedded app-server owned live authorization state used by desktop execution paths. Authenticated webviews took an additional link-session path to establish their browser-scoped session.

This gives the chain four distinct state transitions:

1. the user authorizes a public client through OAuth;
2. the client exchanges and refreshes the resulting authorization state;
3. the desktop attaches the current account authority to requests that require it;
4. only the webview case derives a linked browser session from that authority.

The last transition must not be projected backwards onto Chat. The runtime traces did not show ordinary Chat as a browser-cookie flow. This distinction is one reason a browser automation gateway and the desktop conversation path should not be treated as equivalent merely because both originate from a ChatGPT account.

The traces also preserve a useful negative observation. The renderer could ask the main process to attach several classes of context, including authorization, desktop surface and integrity state. In the executed Flow A/A1 captures, an X-OAI-IS request header was not observed in the captured main-process headers. The Rust client's lower-level request headers were not captured, and the alternative Flow B was not executed. Therefore “not observed in A/A1 at this observation point” is the complete claim; “the product does not use it” would exceed the evidence.

3. Device attestation and proof of work are alternatives, not one ceremonial chain

The integrity investigation initially risked placing every observed mechanism into one linear sequence. Runtime evidence required a different model.

In the macOS Chat path studied, the client requested a fresh challenge and the desktop supplied native device-associated evidence as part of the ensuing conversation transition. The embedded Codex app-server also had an attestation-provider relationship for applicable execution sessions. A Sentinel-style fingerprint and proof-of-work mechanism existed as another branch and was exercised as a fallback surface, but Chat generation through that branch was not validated in this research.

Those mechanisms make different statements. Device attestation ties evidence to a platform or application context. Proof of work demonstrates expenditure against a challenge. A browser fingerprint describes an execution environment. None is interchangeable with OAuth, and none by itself expresses the complete authorization policy.

Figure 2. Authorization, routing and integrity responsibilities reconstructed from the historical desktop environment. The diagram shows alternative branches and the exact evidentiary gaps; it is not a replay sequence.

One failure was especially informative. Extracting and invoking the native attestation component outside its original application context did not reproduce the accepted behavior of the desktop path. That result ruled out a simplistic model in which possession of one component was equivalent to possession of the client environment.

It did not prove which dependency the service rejected. Possible explanations include caller context, surrounding application state, freshness, installation continuity, transport association or another property outside the inspected interface. The correct conclusion is narrower and more useful: the component was context-dependent in the tested arrangement, and server-side evidence would be required to resolve which dependency was decisive.

The absence of an obvious signature at one inspected boundary likewise does not establish that the entire system lacks cryptographic binding. The native component, its caller, the evidence representation, the request transport and the remote verifier are separate observation points. A property invisible at one boundary may be enforced at another.

Proof of work as a performance and security question

The proof-of-work branch also raised a performance question. A client implementation that performs the challenge on a general-purpose CPU may impose latency and energy cost that a parallel backend could change substantially. WebGPU is therefore a plausible experimental candidate.

I did not benchmark it. That omission is deliberate and must remain visible. A faster backend might improve responsiveness, but it could also reduce the intended client cost of the challenge and change its abuse economics. A defensible evaluation would measure latency, energy, device coverage and the relationship between client acceleration and server-side difficulty adjustment. “Move it to WebGPU” is a research hypothesis, not a completed recommendation.

4. The Chat protocol was a conversation tree with client participation

Runtime tracing corrected several assumptions derived from static inspection. The observed interaction had a preparation phase associated with the conversation, a fresh integrity transition, a conversation request containing full user content and client capability metadata, and a streamed response that updated a conversation tree.

The preparation traffic and the submitted conversation had different roles. Partial input could participate in preparation while the completed user message belonged to the actual conversation transition. Multi-turn continuity depended on conversation and parent relationships. The response stream carried structured items rather than only a final text string.

The route families observed in the conversation cycle had discrete responsibilities:

The observed order was preparation, fresh integrity transition, conversation submission and streamed tree updates. On a tool return, the client repeated the stateful conversation transition with fresh integrity material and explicit correlation to the model's tool-call node. Literal authorization material, captured challenge values and complete accepted bodies are excluded here because they add replay value without improving the Blue Team model.

Preparation returned a coordination artifact identified in the research as a conduit token. Runtime correction mattered here too: its existence did not justify inventing a header on the final conversation request. In the validated A1 observations, that proposed placement was not part of the accepted conversation path. This is a small example of a broader rule: discovering a value and discovering where it is consumed are different findings.

For publication, the useful schema is the semantic contract rather than captured one-time values:

{
  "conversation": {
    "action": "next",
    "model_selection": "<selected Chat model>",
    "preparation_state": "<result of preparation>",
    "messages": ["<full user or tool-result message>"],
    "parent": "<previous node when continuing>",
    "integrity_evidence": "<fresh desktop-provided evidence>",
    "supported_stream_encoding": ["<negotiated encoding>"],
    "local_capabilities": ["<client-declared signatures>"]
  }
}

This is not the wire body and cannot be replayed as one. It records the responsibility of each field family: content, continuity, preparation, integrity, stream negotiation and local capability declaration.

The response side was equally important. The model's request appeared as an assistant item addressed to a local capability. Its arguments were structured content. The client intercepted that item, executed the bounded local behavior and submitted a correlated tool-result message into the same conversation. The model then consumed the result and completed the turn.

Figure 3. The completed tool lifecycle. Each arrow corresponds to a distinct observation required to claim more than textual imitation of a function call.

The semantic interface can be represented as three types:

interface LocalCapabilityDeclaration {
  name: string
  description: string
  parameters: Array<{ name: string; required: boolean; schema: unknown }>
}

interface ModelRequestedLocalAction {
  conversationNode: string
  capability: string
  arguments: unknown
  channel: 'tool-trail'
}

interface ClientReturnedLocalResult {
  correlatesTo: string
  capability: string
  result: unknown
  continuesConversation: true
}

These types preserve the protocol's ontology without publishing captured identifiers, tokens or a literal accepted request. The decisive relationship is correlation: a declaration makes a capability available; a model item requests it; the client performs it; a result node refers back to the request; the conversation continues.

The wire-level names that carried those responsibilities were more specific:

This mapping explains why copying a function schema is insufficient. The declaration, addressed model item, client dispatch, correlated result and continued tree are separate pieces of protocol state. The research established all five pieces in the completed loop.

The built-in handoff behavior supplied the comparative model. Chat could offer a local function that redirected suitable work into Work mode. The research asked whether the same client-declared mechanism could represent another bounded local capability. The two successful interactions established that it could under the tested conditions.

Handoff as the product's own reference implementation

Handoff connected the product surfaces without making them identical. Chat declared the function locally; the model could request it; the desktop created or associated work on the Work side; and the outcome returned to the Chat conversation as a tool result. The Work task then belonged to the Codex execution lifecycle, where thread events, tool items and usage updates were observable through the embedded app-server.

That bridge supplied two important controls for the experiment. First, it proved that a local function call in Chat was not merely a theoretical schema left in the bundle. Second, its returned conversation node showed how the official client represented the result of client-side work. The custom capability was compared against that product behavior at the level of message roles, correlation and continuation—not against an invented standalone tool protocol.

The accounting implication follows the transition. A handoff begins as a Chat-side model decision but can cause Codex-side work whose usage is reported by the execution system. The custom tool remained local and returned directly to Chat. A Blue Team review should therefore ask whether capability policy and accounting follow the downstream work caused by a call, rather than only the surface that emitted the call.

5. Bezetacil turned the application into an inspectable experiment

Static reverse engineering exposed candidate paths, builders and interfaces. It could not identify which path a live interaction actually used. Bezetacil v6 supplied the missing experimental layer: in-process instrumentation, separately managed observation modules, session-oriented telemetry and revision identity for the active scripts.

The harness had its own lifecycle because instrumentation can alter the system being measured. If an old hook remains active beside a revised hook, one event may be recorded twice or under incompatible assumptions. If output from different sessions is merged, a one-time transition can appear reusable. If the researcher cannot identify which script revision produced a record, later interpretation becomes guesswork.

Bezetacil therefore separated:

• the manager responsible for loading, replacing and identifying instrumentation;
• modules responsible for one observation concern;
• session records responsible for keeping experiments apart;
• cross-runtime correlation responsible for relating renderer intent, main-process transport and app-server behavior.

This infrastructure did not make every interpretation correct. It made interpretations falsifiable. The strongest moments in the investigation came when runtime traces contradicted the current model and forced a new one.

From Claude Desktop instrument to a reusable research architecture

Bezetacil did not begin with ChatGPT. Its first mature form came from my reconstruction of Claude Desktop, where the problem was how to inspect and modify an Electron application without rebuilding its complete archive after every experimental change. The early toolset combined ASAR extraction, deobfuscation, a bootstrap loaded into the Electron main process, debugger-based network observation and hot-reloaded scripts.

That origin shaped the ChatGPT version. The Claude work had already demonstrated that static bundle analysis and runtime observation answer different questions. It had also exposed a serious instrumentation problem: naïvely loading successively numbered script revisions caused multiple handlers to coexist, producing duplicate events and misleading output. A fixed script identity and an explicit unload contract became necessary parts of the method.

Bezetacil v6 generalized those lessons into two script classes. Hooks attach observers and remain active for the session. Triggers register an operation but do nothing until invoked. The manager maintains a registry containing each script's source hash, activation time, mode and teardown function. When source changes, the manager unloads the previous instance before activating the new one. Disabled scripts remain visible on disk without participating in the runtime.

The distinction is methodological, not cosmetic. A network observer should remain active while a one-time state inspection should not. Treating both as automatically executing scripts makes the act of loading research code indistinguishable from performing the experiment.

The ChatGPT harness added session log rotation and separately named JSONL streams for network traffic, attestation transitions, response SSE, WebSockets and app-server stdio. This allowed one visible interaction to be correlated across Electron's renderer and main process and the embedded Rust app-server. The loopback control surface exposed lifecycle and inspection operations to the researcher without making every experiment part of the permanent bootstrap.

The resulting architecture had four trust boundaries of its own:

Bezetacil is therefore more than the mechanism used to capture this result. It is part of the research contribution: an instrument designed so that its own lifecycle can be distinguished from the lifecycle of the target.

6. The failures reconstructed the real boundary

The failed experiments are not a blooper reel. They identify which equivalences did not hold.

Failure class A — static possibility presented as runtime behavior

Early reconstruction combined fields and paths that existed in code into a single imagined flow. Runtime traces showed that the desktop Chat path selected different integrity behavior and different field semantics. The correction was to treat static analysis as a map of possibilities and runtime traces as evidence of selection.

Failure class B — OAuth treated as the complete authorization context

A valid authorization family did not make a standalone request equivalent to the live application. The correction was to model installation context, device state, integrity evidence, freshness and conversation lineage separately.

Failure class C — copied state treated as reconstructed state

Reusing a captured identifier can make one request look closer to the original while teaching nothing about how the identifier is created, persisted or bound. The research shifted from copying values toward reconstructing their lifecycle and reading live state from the component that owned it.

Failure class D — mixed transports inside one comparison

Some transitions were performed through different network paths while being described as one experiment. That breaks causal interpretation: a rejection may reflect path inconsistency rather than the field under study. The correction was a same-path invariant for transitions that belong together.

Failure class E — verification consumed the state it was meant to verify

A check repeated an operation involving fresh or consumable state. The subsequent rejection was nearly labeled as a service cooldown. The experiment itself had changed the condition. The correction was to inspect state between consequential actions and stop turning verification into another untracked trial.

Failure class F — a plausible diagnosis outran the observation

Several rejected operations admitted multiple explanations. Naming one explanation too early produced a causal story without discriminating evidence. The correction was to record symptom, experimental difference, competing hypotheses and the evidence required to choose among them.

Failure class G — a model described the right invariant and violated it in implementation

The agents assisting the research sometimes articulated the need for shared state, correct authorization or consistent transport and then produced tooling that did not preserve it. This is a substantive agentic-systems failure: natural-language awareness of a constraint is not enforcement of that constraint. The researcher must make invariants executable or inspect them at every transition.

Figure 4. The evidence ladder used to prevent a final success from erasing the corrections that made it interpretable.

7. What the public vendors clarify—and what they do not prove

The local source review compared OmniRoute, openai-oauth and an additional Codex-oriented client implementation. They are useful controls because they divide the problem differently.

The source comparison identified concrete mismatches between some community implementations and the desktop behavior studied: different integrity families, different environmental state, incomplete conversation context or a gateway translating a contract without reconstructing the official client's surrounding lifecycle.

The specific OmniRoute chatgpt-web path

The vendored snapshot contains more than one OpenAI-related provider. The relevant comparison here is its chatgpt-web executor, which targets the browser-session surface rather than the Codex OAuth surface.

Its pipeline begins from user-supplied browser session state. It exchanges that state for a short-lived account token, derives a stable device-shaped identifier from the credential, and assembles browser-like request metadata. Before generating, it performs a group of page-load-style requests, retrieves current deployment information from the site, prepares Sentinel requirements, solves a requested proof-of-work challenge and submits a conversation through the web backend. It then translates ChatGPT's streamed response into an OpenAI-compatible response.

The implementation is explicit about why those steps exist: its warm-up traffic and deployment scraping are attempts to make the resulting session resemble ordinary browser behavior to Sentinel. If the site requires an interactive Turnstile token, the executor can accept one from provider-specific state. The source also maintains rotated session-cookie material and clears cached authorization after some upstream rejection classes.

Its tool support is a second, independent translation. The web provider does not use the Desktop mechanism I observed. When an incoming compatible request contains tools, OmniRoute adds a textual tool contract to the prompt, buffers the model response, parses specially delimited tool text and emits synthetic OpenAI tool_calls. This is prompt-mediated emulation. The Desktop result used a structured client declaration, a model item addressed to a local recipient, a correlated tool-result node and normal conversation continuation.

This is the strongest reason not to describe the two approaches as incomplete versions of one another. OmniRoute is reconstructing enough of a browser client to provide a compatible service. My research used the running Desktop as the state and transport authority to test whether its native Chat protocol admitted a custom client-executed capability.

Why I stopped before turning proof of work into the project

The Sentinel branch was observed and its fingerprint structure compared, but I did not use it to complete Chat generation. Continuing would have changed the center of gravity of the disclosure. The research would have moved from characterizing a Desktop capability boundary toward improving reproduction of the browser anti-abuse path—the exact domain the OmniRoute executor already attempts to operationalize.

That missing experiment is protective negative space. It leaves unanswered whether a reconstructed browser client could preserve acceptable account behavior over time, how enforcement would classify it, which attributes are decisive, and how challenge performance interacts with risk. Those are precisely the facts someone would need to turn a protocol description into an abuse playbook.

The Blue Team still receives the useful comparison: one public implementation combines credential-derived identity, browser mimicry, session warm-up, deployment scraping and proof of work; the Desktop path selected native attestation and native client-declared tools instead. The report exposes the mismatch and the candidate detection surfaces without determining how to erase them.

Those mismatches are relevant to rejection. They are not sufficient to explain bans.

No account was banned in my experiment, and I deliberately did not search for the threshold or behavior that would avoid enforcement. Reports of bans associated with community tools may be consistent with anomalous client behavior accumulating account risk, but that remains a hypothesis unless it is connected to service-side enforcement telemetry or a controlled account-level study. The report therefore gives the Blue Team candidate signals to investigate without giving a third party a recipe for evading those signals.

Candidate defensive observations include unexpected combinations of authorization family and client context; integrity evidence inconsistent with the claimed surface; repeated failures involving fresh state; conversation transitions that do not preserve normal lineage; and sustained automation whose workload no longer resembles interactive use. These are review questions, not confirmed production detectors.

8. Why the completed tool loop changes the threat model

A conversational client traditionally mediates user input and model output. A client-executed tool protocol adds two forms of authority:

1. the client can declare capabilities that affect what the model may request;
2. the client can translate a model request into effects outside the model and return those effects as trusted conversation state.

The result is not automatically a vulnerability. It is a programmable boundary. Its security depends on who may declare capabilities, how the service distinguishes product surfaces, whether local effects require user approval, how tool results are correlated and whether usage accounting follows the inference and execution pattern actually produced.

An OpenAI-compatible proxy is therefore an architectural extrapolation with several missing proofs. It would require a durable session controller, request/response translation, streaming adaptation, conversation-state management, tool dispatch, error recovery and sustained behavior under product controls. The experiment established one crucial primitive: custom local execution could participate in the Chat conversation loop. It did not establish that the remaining system would operate reliably, permissibly or indefinitely.

That difference should sharpen the response rather than weaken it. Product security does not need to wait for a public production proxy before reviewing whether the primitive crosses an intended boundary.

9. Concrete questions for an OpenAI Blue Team

The report supports a bounded set of engineering questions:

• Does server-side policy bind client-declared capabilities to the product surface and authorization context in which they appear?
• Can a Chat interaction declare arbitrary local capabilities, and is that behavior intended outside the official handoff mechanism?
• Does the accounting system classify work by UI surface, transport, model workload, declared capability or another server-side property?
• Are integrity challenges bound to the specific request, conversation transition, installation context and transport that consume them?
• Do rejection diagnostics distinguish expired state, invalid lineage, failed integrity evidence and unauthorized capability expansion?
• Are account-level enforcement decisions observable separately from request-level rejection, so that compatibility failures are not mistaken for ban causes?
• Can anomalous combinations of browser state, OAuth family, device context and conversation behavior be reviewed without creating brittle fingerprints?
• Would accelerating proof of work change only client performance, or would it undermine the intended economic cost of the challenge?
• Are handoff and other local functions represented by a narrow allowlist, a capability policy, or merely by client-provided declarations?
• Can tool results introduce content or authority that the service treats differently from ordinary user messages?

These questions separate defense from speculation. Each can be investigated with server-side evidence unavailable to an external researcher.

10. Claim ledger

11. Why I stopped

I stopped after the second successful custom-tool interaction because the original protocol question had been answered. Continuing into sustained automation would have changed both the research question and the risk profile. It would no longer have been a bounded demonstration of client participation; it would have become an evaluation of operational access, accounting and enforcement.

That boundary is deliberate. It allows the completed experiment to be described in technical depth while leaving unanswered the information most relevant to abuse: durability, volume, detection thresholds and evasion behavior.

The work still demonstrates the capabilities I intended it to demonstrate. I reconstructed a multi-runtime desktop client, corrected static assumptions with live evidence, designed an instrumentation lifecycle, separated authorization from integrity and conversation state, turned failures into protocol constraints, and completed a client-executed tool loop on the product surface under examination.

The model requested my capability. The client executed it. The result entered the conversation. The model continued.

That is a small sequence with a large architectural consequence.

Contact and coordinated review

If an OpenAI security or engineering reviewer identifies a concrete disclosure concern, please contact me at me@aleffita.dev. I am willing to coordinate a human-reviewed assessment and, where appropriate, temporarily remove or revise affected material while the concern is evaluated.

I am open to research engineering, product security and application-security work at OpenAI. This investigation reflects the work I want to continue: reconstructing complex behavior across runtime boundaries, designing instruments that make hypotheses testable, and converting ambiguous observations into engineering decisions.

This article documents a historical desktop build and a bounded research environment. It should not be read as a statement that the same behavior persists in the current release.

Related research in WikiFita

• OpenAI desktop research hub
• Vendor analysis: OmniRoute, openai-oauth and related clients
• Bezetacil Toolset: Electron runtime introspection
• Search WikiFita for ChatGPT Desktop
• Search WikiFita for Bezetacil