{"version":"2.1.290","anchor":"cloud-session-create-session-id-display-and-failure-telemet","canonical_anchor":"cloud-session-create-session-id-display-and-failure-telemet","heading":"Creating a cloud session now reports what was not applied","tier":"notice","area":"Cloud Sessions","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.290\/e\/cloud-session-create-session-id-display-and-failure-telemet","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.290","markdown":"### Creating a cloud session now reports what was not applied\n\nThe cloud-session create command now prints the session ID, a notice and a not_applied list, and names the agent that requires a repository\n\n**Unclear.** What the session ID formatter changes about the printed ID is not clear.\n\n**What**\n\nThe command that creates a cloud session (`pool_headless`) reports more about the result.\n\n- It prints a notice and a `not_applied` list of the parts of your request that the cloud session did not apply.\n\n- The session ID is printed on its own, in a set format.\n\n- The JSON output, the machine-readable form, adds `notice` and `not_applied`. Before, it held only `ok`, `session_id`, `title`, `url` and `pool_id`.\n\n- The create call passes `repositoryRequiredBy`, which names the agent that needs a repository.\n\n- Error reports can include `message_hidden`. Errors are no longer handled by the old exit step.\n\n- The create flow now tells the device bridge and served tools that a cloud client is involved (`cloudClient: true`).\n\nNothing has been read about the gate `tengu_remote_create_session_error`.\n\n**Why**\n\nYou can now see which parts of your request the cloud session did not apply. Scripts reading the JSON output gain two new fields to handle.\n\n- Area: Cloud Sessions\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}