[ChatGPT][Work handoff] AI-initiated Chat → Work unavailable in an existing conversation despite Work access

Summary

In an existing ChatGPT conversation, the assistant correctly recognized that Chat → Work handoff is an official product capability, but reported that the AI-initiated Work handoff action was not present in the callable operation/tool surface for that conversation.

Work itself is available on the account, and I can start Work manually. The failure therefore appears to be specific to capability exposure for this Chat/conversation rather than a general Work entitlement problem.

I am intentionally omitting account identifiers, conversation IDs, project names, local file paths, screenshots, and task contents from this public report.

Observed behavior

The conversation had already developed substantial context. When asked to hand the task off to Work, the assistant first said it could not create/send a Work task from that Chat.

After being asked to verify the official feature, the assistant confirmed that Chat → Work handoff exists, but then reported, in substance:

The official UI path for continuing a Chat in Work exists, but in this response the operation for issuing a Work transition card / creating a Work task is not present in the callable operation list.

The assistant also checked the extension/plugin side and correctly noted that absence there would not prove that the first-party ChatGPT feature is unavailable.

I ultimately started the Work task manually, so the underlying Work feature itself was usable.

Why this looks like a capability-exposure issue

This resembles a class of bugs where a product capability exists and entitlement is valid, but the model-visible callable catalog for a particular session omits the effectful handoff action.

Potentially related reports:

• #42500 — manual “Transfer to Work” disappeared from existing Chat conversations on macOS while AI-initiated handoff still worked. This report is effectively the opposite direction: Work exists, but the AI-initiated handoff surface was unavailable in the affected conversation.
• #40852 — effectful first-party task tools omitted from the callable catalog while read-side tools remained available.

I am not claiming these share the same root cause, only that the capability/catalog mismatch is similar.

Steps to reproduce

I do not yet have a deterministic cross-account repro, but the observed path was:

1. Open an existing ChatGPT conversation with substantial prior context.
2. Confirm that the account has access to Work and that Work can be started manually.
3. Ask the assistant in that conversation to continue/hand off the task to Work.
4. The assistant inspects its available operations and reports that no callable Work handoff / task-creation action is available for that response.
5. Start Work manually from the product UI; it succeeds.

A fresh Chat may behave differently, but I did not spend additional usage reproducing this after manually continuing the task.

Expected behavior

When Work is available to the account and the user explicitly requests a Chat → Work handoff, the Chat session should expose the official AI-initiated handoff capability consistently.

If the capability is intentionally unavailable for a particular conversation, client, or session state, ChatGPT should expose a structured reason (for example: client limitation, conversation-state limitation, rollout/entitlement state, or policy restriction) rather than making the model infer that the operation simply does not exist.

The manual UI path and AI-visible capability catalog should remain consistent enough that users are not told contradictory things about whether Chat can initiate Work.

Privacy / security

No private conversation content, local paths, task instructions, account identifiers, device identifiers, credentials, tokens, or conversation IDs are included here. More detailed diagnostics can be provided through a private support/feedback channel if maintainers need them.

The report names no repository files, tests, or entry points. Start by reproducing the handoff request in an existing conversation and compare its callable operation surface with a fresh Chat and the manual Work path. Done means the AI-initiated handoff is consistently exposed when Work is available, or the session reports a structured reason when it is not.