Problem
The CLI currently makes it easy to work with:
- spaces (
clickup space list)
- sprint lists (
clickup sprint list, clickup sprint current)
- tasks in a known list (
clickup task list --list-id ...)
But it does not expose a dedicated way to discover regular folders and regular lists inside a space.
In practice this means that when automation or AI agents need a list_id for a non-sprint workflow, they must either:
- already know an existing task from that list and inspect it, or
- bypass the CLI and call the ClickUp API directly.
Why this matters
We use ClickUp for more than sprint work.
A common workflow is:
- create tasks in the current sprint when the work belongs to the active sprint
- create tasks in a regular project list or backlog when the work should not go straight into the sprint
Right now the CLI is great for the sprint case because clickup task create --current works well.
The gap is the non-sprint case: there is no first-class CLI way to discover folders and regular lists before creating a task.
This makes automation harder, especially for agentic workflows where we want to choose the correct destination list programmatically instead of defaulting everything into a sprint.
ClickUp API references
The public API already exposes the primitives needed for this:
- folderless / space-level lists:
- folders in a space:
- lists inside a folder:
Example API calls
curl -s -H "Authorization: <token>" \
"https://api.clickup.com/api/v2/space/<space-id>/list?archived=false"
curl -s -H "Authorization: <token>" \
"https://api.clickup.com/api/v2/space/<space-id>/folder?archived=false"
curl -s -H "Authorization: <token>" \
"https://api.clickup.com/api/v2/folder/<folder-id>/list?archived=false"
Proposed CLI support
A proposal that feels consistent with the current CLI shape:
1. Add folder discovery
clickup folder list --space <space-id>
clickup folder list --space <space-id> --json
This would expose folder IDs and names.
2. Add regular list discovery
clickup list list --space <space-id>
clickup list list --space <space-id> --folderless
clickup list list --folder <folder-id>
clickup list list --space <space-id> --json
This would expose list IDs and names without requiring an existing task.
Alternative
If you want to avoid adding both folder and list top-level groups, even a single command that solves discovery would help a lot, for example:
clickup folder list --space <space-id> --include-lists
The key thing is having a supported CLI path to discover:
- folder IDs
- regular list IDs
- non-sprint destinations
without falling back to raw API calls.
Problem
The CLI currently makes it easy to work with:
clickup space list)clickup sprint list,clickup sprint current)clickup task list --list-id ...)But it does not expose a dedicated way to discover regular folders and regular lists inside a space.
In practice this means that when automation or AI agents need a
list_idfor a non-sprint workflow, they must either:Why this matters
We use ClickUp for more than sprint work.
A common workflow is:
Right now the CLI is great for the sprint case because
clickup task create --currentworks well.The gap is the non-sprint case: there is no first-class CLI way to discover folders and regular lists before creating a task.
This makes automation harder, especially for agentic workflows where we want to choose the correct destination list programmatically instead of defaulting everything into a sprint.
ClickUp API references
The public API already exposes the primitives needed for this:
GET /api/v2/space/{space_id}/listGET /api/v2/space/{space_id}/folderGET /api/v2/folder/{folder_id}/listExample API calls
Proposed CLI support
A proposal that feels consistent with the current CLI shape:
1. Add folder discovery
This would expose folder IDs and names.
2. Add regular list discovery
This would expose list IDs and names without requiring an existing task.
Alternative
If you want to avoid adding both
folderandlisttop-level groups, even a single command that solves discovery would help a lot, for example:The key thing is having a supported CLI path to discover:
without falling back to raw API calls.