Skip to main content
comet resume-probe solves the “recovery recognition” problem in long-running work. Typical case: you want to continue an existing Comet change, but the session, context window, or device has changed. The Agent no longer has continuous chat context, and no new /comet trigger was issued. The probe performs a read-only comparison between the current request and active changes, then decides whether to return to Native or Classic. This prevents the Agent from misclassifying “continue the previous login refactor” as a brand-new task. It first reads project .comet/config.yaml to determine Native or Classic, then reads only the active changes, current phase, and user request for that workflow. Old Classic projects without valid workflow config use legacy fallback. If configuration is corrupted, probing stops and requests repair instead of scanning the other workflow. The probe only returns recognition and routing results. It does not modify changes, advance phases, choose among multiple changes, or execute commands. The Agent should call /comet-native or /comet-classic according to nextCommand.

​
Why is it necessary to restore the detection

Long-distance tasks do not necessarily always remain in the same complete context. The following situations may all cause the Agent to forget that the current job was originally managed by Comet:
  • The dialogue undergoes context compression, window switching, or starts a new session;
  • When a user changes equipment, they continue to use the same warehouse and change.
  • The new Agent can only see the disk status and the sentence “Continue with the previous work.”
  • The user naturally requested to continue the task, but did not enter /comet again.
The Comet recovery description written by the project initialization enables the Agent to invoke the recovery probe before processing such requests. The probe returns interpretable results based on configuration, active change, stage, selection, and request text: It provides the correct permanent Skill entry when the target is unique, asks only once when the target is unclear, and remains in the normal conversation when it is truly irrelevant.
Restoring detection does not require users to remember an additional command. It is mainly called by agents and project recovery descriptions to bridge the gap between natural language continuation and the explicit /comet entry.

​
How does automatic detection occur

Users do not need to input comet resume-probe. Normal interaction still directly tells the Agent:
Continue with the login refactoring just now.
comet init and comet update will write the recovery instructions into the project’s Agent instruction file. When ambient_resume is enabled, the Agent will automatically run a read-only recovery probe before processing natural language requests that may be long-term tasks:
  1. Read the project configuration to determine whether Native or Classic should be checked.
  2. Compare user requests, active changes, current stage and selection;
  3. When the target is unique, press nextCommand to re-enter the corresponding /comet-native or /comet-classic.
  4. When the goal is ambiguous, only ask the user one question. When the request is irrelevant, handle it normally and do not enter Comet.
When explicitly calling /comet, it will directly enter the workflow according to the project configuration without relying on automatic detection. The ** non-Comet ** Skill or slash command explicitly invoked by the platform does not trigger the recovery probe either - the task intent has been clearly defined by this call, and the Skill can be directly executed. If the project is set to ambient_resume: false, ordinary natural language requests will not trigger environmental awareness detection, but /comet is still available.
For users, the recovery detection is automatic. The following CLI parameters are used for Agent, Hook, project instructions, and automation integration, and are not steps that must be manually executed before restoring tasks.

​
Reference for Agent and Automation Integration

An Agent or integrator can directly pass in requests:
It can also be read from standard input:

​
How to understand the result

JSON uses comet.resume_probe.v2, including workflow, skill, entrySource, reasonCode, candidates, changeName, phase, nextCommand and judgment evidence. Native restores at any stage through /comet-native. comet native next is a status advancement command, not a recovery entry. The internal v1 probe of Classic’s built-in runtime remains compatible, but the top-level CLI returns v2.

​
Under what circumstances will it definitely be suspended

  • Multiple active changes, but the user request did not name the target.
  • Multiple active changes without valid selection or user roll call.
  • The active change lacks a valid status or the project configuration is damaged.
  • Currently, it is at user decision points such as plan-ready, verification failure, and archive confirmation.
  • When the request is not related to an existing change or is merely an information query, it will not be restored but will return out_of_scope.
The unsubmitted changes of Native are only used as recovery evidence and reminders, and will not separately block strong models from entering the /comet-native inspection site. Classic continues to retain the rule for confirming the ownership of the working tree.
ask_user This result indicates insufficient evidence or that the process is waiting for the user to make a choice, which is a normal pause state. The caller should present the reasons and ask the user. Repeated operation of the recovery detection fails to complete the required evidence.

​
The difference from other commands

​
Next step

  • Restoring Interrupted work ](/en/guides/resuming-workflow) - Natural Language Recovery and the usage of explicit /comet
  • Status Damage and Recovery - How to Troubleshoot When the recovery detection prompt indicates an abnormal status
  • comet status - View the detailed status of all active changes
Last modified on September 4, 2026