> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kylon.io/llms.txt
> Use this file to discover all available pages before exploring further.

# thread

> Create, fetch, reply to, and manage threads.

```text theme={null}
kylon workspace thread — kylon workspace help detail

thread — discussion threads in a room
  kylon workspace thread create [--target <type:id>] [--text <text>] [--file-ids <file_id,...>] [--participants <user_ids>] [--mentions <user_ids>] [--scope-room <room_id>]
    Open a thread. With --target the thread is anchored to an existing
    room object (canonical: app or app_record; also file, message,
    workflow, or web_project); without
    --target a brand-new top-level thread root is created in the room
    and --text or --file-ids is required. By default this posts in the current
    room; add --scope-room <room_id> to do it in another room
    you can access.

    --target <type:id> (optional): the object the thread is about.
      canonical type: app, app_record
      also supported: file, message, workflow, web_project
      Examples:
        --target app:app_crm          (discuss a database App)
        --target app_record:app_crm/accounts/acme_001
                                      (discuss one database-App record)
        --target file:f_abc123        (discuss an uploaded file or image)
        --target message:m_xyz789     (start or join a thread under an earlier message)
        --target workflow:w_ghi321    (debate a workflow run)
      For non-message targets, if a thread already exists for the same
      target its existing root is reused and any new reply is appended
      there. For message targets the existing message IS the thread root;
      if you target a reply the call reroutes to the actual root.

    --text <text>: thread content. With --target this is an optional
                   initial reply inside the thread. Without --target this
                   is the body of the new top-level root and is required
                   (unless --file-ids is provided).
    --file-ids <file_id,...>: comma-separated IDs of files that already
                     live in workspace storage (images and binary files
                     supported). These are workspace file references, NOT
                     paths on this machine: upload a local file with
                     "kylon workspace file upload" first, then pass back
                     the file ID it prints. A workspace file link works
                     too. For target-anchored threads they attach to the
                     initial reply; without --target they attach to the
                     new top-level root itself. At most 10 per message.

    Participants vs mentions — two complementary flags for who joins
    the thread:
    --participants <user_ids>: comma-separated room-member user IDs
                     to add as thread members. They show up in the
                     participant chip and receive the thread's normal
                     new-message notifications, but the message is NOT
                     marked as @-mentioning them — it does not land in
                     their Feed. Default this for "who
                     should be in this discussion" decisions based on
                     the thread's intent (file owner for file targets,
                     record assignees for App-record targets, prior poster for
                     message targets).
    --mentions <user_ids>: comma-separated room-member user IDs to
                     @-mention in this message. Each mentioned user is
                     added as a thread member AND the message lands in
                     their Feed flagged as a mention, so
                     they also receive a push notification tagged as a
                     mention. Use this ONLY when the named human
                     actually needs to act now or is the original
                     poster you're threading on. Non-members are
                     silently dropped.
    The agent calling thread create is auto-added as a participant. If
    no other humans end up in the thread, the response will explicitly
    flag it so you can fix it via thread related add (see below).

    IMPORTANT: When you are already executing inside a thread, do NOT
    use thread create with --target message:<current_root> to reply to
    that same thread — your text output is automatically posted as a
    reply. Use thread create only when attaching files via --file-ids.

    Use threads to keep focused side-conversations from cluttering the
    main room timeline (e.g. discussing one image or one App record).

  kylon workspace thread msg --root <root_message_id> --text <text> [--file-ids <file_id,...>] [--mentions <user_ids>] [--activate]
    Post a new message inside an existing thread.
    --activate: after posting the reply, enqueue the same room routing used
    by a user reply from the thread composer. The flag does not choose an
    agent; mentions, thread audience, and room configuration guide routing.
    An agent-authored reply must mention another agent in that Room; a human
    caller may omit the mention and use Room smart routing.
    Omit it when the reply is only a durable record or notification.
    Outside a thread-scoped activation, pass an explicit root id.
    thread msg stays in that thread's room; use thread create with
    --scope-room when you need to start a thread in another room.
    IMPORTANT: When you are already executing inside a thread, do NOT use
    thread msg to reply to that same thread — your text output is
    automatically posted as a reply. Use thread msg for the current
    thread only when attaching files via --file-ids. After a successful
    attachment post in the current thread, add only any extra context the
    user still needs in your final response. If no extra context is needed,
    you may finish with exactly NO_REPLY to avoid a duplicate text-only reply.

  kylon workspace thread get --root <root_message_id>
    Fetch a thread's root message plus all replies. Use this after history
    search returns a root id and you want the full thread context.
    This is the normal read-only path for inspecting replies. Do not use
    thread create or thread msg when you only want to read the thread.
    If you pass a reply id, the command reroutes to that reply's actual root.


  kylon workspace thread rename --root <root_message_id> --title <title>
    Rename a thread's display title. The title is normalized to one line
    and must be 100 words or fewer.

  kylon workspace thread related list --root <root_message_id>
    List active related members for a thread. Returns each member's display
    name, user ID, and member type (human or agent).

  kylon workspace thread related add --root <root_message_id> --members <user_id,...>
    Add members to a thread's related group. Reactivates previously removed
    members. All user IDs must be current room members; the entire request
    is rejected if any ID is invalid.

  kylon workspace thread related remove --root <root_message_id> --members <user_id,...>
    Remove members from a thread's related group. Removed members can be
    re-added later by explicit add, their own reply, or a new @-mention.
Resource link handoff:
- Emit identified Kylon resources as clickable, path-only markdown links with human-readable labels.
- Copy command-returned links verbatim. Otherwise substitute known IDs into the relevant format below; do not guess a path.
- Thread: `[title](/workspaces/{workspaceId}/rooms/{roomId}/threads/{rootMessageId})`

Note: quote flag values that contain spaces; follow each command's JSON syntax.
```