{"version":"2.1.248","anchor":"text-a-client-already-composed-is-no-longer-re-parsed-as-a-s","canonical_anchor":"text-a-client-already-composed-is-no-longer-re-parsed-as-a-s","heading":"Text a client already composed is no longer re-parsed as a slash command","tier":"notice","area":"Slash Commands","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/text-a-client-already-composed-is-no-longer-re-parsed-as-a-s","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Text a client already composed is no longer re-parsed as a slash command\n\nText your client already composed is sent as written, even if it starts with a slash.\n\n**What**\n\nMessages arriving with `client_composed` set are now enqueued with slash-command parsing skipped, so a message that happens to start with `\/` is sent as written. Messages with either `client_composed` or `seeded_summon` also skip attachment expansion, so `@file` references are not materialised a second time.\n\n**Details**\n\n- Applies in the stdin and remote-IO inbound message loop.\n- No flag; the behaviour follows entirely from the flags on the incoming message.\n\n**Evidence**\n\n`...(r.client_composed === !0 && { skipSlashCommands: !0 }),`\n\n- Area: Slash Commands\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 3\/5"}