Board & Subtask Visibility
Every board has a Visibility setting that controls which task and subtask encodings are exposed. This setting is applied consistently across all surfaces where a board is viewed or acted upon and can be overridden in the Board hierarchy.
Board visibility modes
Section titled “Board visibility modes”A board’s top-level setting is configured from the board’s header, using Ctrl+K → “Edit board visibility” (or via the context menu). The available modes are:
| Mode | Description | Conflicts with inherited |
|---|---|---|
| Visible | All task and subtask fields are shown. | No |
| Basic | Only the title and description of tasks are shown. | Partial (core fields may still be inherited) |
| Dimmed | Visibility applies to the owning team only (BYOK & free teams are effectively Hidden). | No (inherits from parent if permitted) |
| Hidden | Layout shows only the owning team; other teams see an empty placeholder. | Only the owning team |
Saved-view subtask controls
Section titled “Saved-view subtask controls”When access is Visible, saved views can further restrict subtask visibility via a new subtask controls property. This property is stored as part of the saved view’s view_query payload and affects read responses from:
- CLI (
--tasks/view show) - MCP tools
- Board & table API endpoints
- AI Chat create/update actions
Supported modes are enumerated in the table below, and they behave consistently when read through any surface:
| Mode | CLI / MCP / API / AI Chat read effect | Notes |
|---|---|---|
| Visibility — all | All task and subtask fields are shown. | Default when the board visibility is Visible |
| Visibility — basic | Only title and description are shown. | Same behavior as board-level Basic |
| Visibility — disabled | Subtasks are omitted from read and create responses. | Subtasks cannot be created or shown; displaySubtasks appears as false |
| Visibility — inherited | Subtasks follow their parent board’s visible sections. | Used when a parent board or saved view explicitly sets this mode |
Rail and sidebar behavior
Section titled “Rail and sidebar behavior”When you disable the Rail (sidebar) in Appearance settings, the following applies:
- Rendering: On client-side hydration, the rail is immediately hidden. Before hydration completes, an early SSR pass may briefly render it alongside the main view.
- User-visible fix: Rail-off users no longer see this flash during page load. After the initial SSR render is removed under strict hydration guards, the UI stabilizes without the rail ever being visible.
- Consistency: The rail-off state is enforced across all pages and views, ensuring a clean workspace for users who prefer a focused, rail-free app surface.
Why use visibility modes?
Section titled “Why use visibility modes?”- Free and BYOK users can share boards with inner-team guests by setting the board to Dimmed; guest users see placeholders for other teams.
- Boards that are shared externally may set visibility to Basic to limit detailed data that isn’t relevant to external collaborators.
- Bot agents and scheduled MCP pipelines may use Disabled subtask visibility in saved views to reduce payload size and operational noise.
- Kanban vs table layout compatibility—low-detail modes ensure consistent views regardless of whether you are looking at cards or a table, without changing board-level visibility.
Keyboard shortcuts
Section titled “Keyboard shortcuts”From a board’s header:
- Ctrl+K → Edit board visibility (opens a context menu with the four board modes)
- Ctrl+K → Save view (creates or updates a saved view with any displaySubtasks mode)
From any board or task list:
- Ctrl+S (on a view) → Save as view (opens a dialog; includes a Display subtasks toggle)
References
Section titled “References”- Browse features