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

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 access control

Security fix Saved-view endpoints now respect board membership data. Before requests are processed, Hypertask validates whether a user has access to the board that owns the saved view:

Block access – requests from users not on the board (including through chat API and MCP) are met with a 404 Not Found result.
Reject unauthorized reuse – callers cannot rename, delete, or switch to saved views on boards they cannot access.
Preserve their own data – your own board still lists its saved views, exactly as before.

This change ensures saved-view endpoints are scoped strictly, preventing cross-board data leakage through saved-view references or AI‑assisted view actions.

Profile details in board detail answers

Security fix Board detail answers now safely expose profile information. Before this fix, a board detail answer would show every profile field of the board owner and task assignees, including private details. After this fix:

Private profile visibility – Board members no longer see private profile details of the board owner or assignees.
Limited exposure – The old board detail answer now shows each person with only their id, name, and photo.
Consistent behavior – This applies to API responses that include profile details for tasks and owners, so public references (links, summaries, and views) respect the same privacy boundaries.

Why this matters

Boards with strict visibility settings can share detail previews without leaking sensitive profile data.
Agents and MCP tools that query board details show profile data consistent with visible vs. hidden modes.
Saved-view and AI-chat integrations that render profiles stay within the same privacy model as other board filtering.

Board access for reads

Security fix Hypertask now properly restricts board-visible resources (tasks, pages, tables, and column names/settings) to users who have access to the board. Standard tasks, tables, and pages show only work that belongs to boards you are a member of. Before this fix:

Page access leak – a page would keep its old-board access even after its task moved to another board, so users without access to the new board could still open and search the page.
Column visibility leak – any logged-in user could read another board’s column names and settings, including through search filters and tables.
Cross-board exhaust – a board member could search across all boards and open test pages, exposing additional columns and configuration.

After the fix:

Moving a task moves its pages – when you move a task to another board, its pages are now restricted to users with access to that board. Users who cannot see the new board cannot open or search the page.
Columns are board-scoped – columns and their associated layout/filter settings from boards you're not on are hidden. Only your boards contribute to search results and table columns.
Search is scoped properly – global search, filtered tables, and the search screen only return content you have board access to; cross-board data is filtered out at the backend.

Why board-aware access matters

Prevents unauthorized access across unrelated workspaces at a single login.
Aligns searches and tables with your effective board memberships.
Keeps pages in context – pages follow their task and stay visible only to the people who can see the new board.

Board access for writes

All write paths consistently enforce membership-based access before mutating targets. Members cannot bypass access checks by switching identities or relying on CLI/MCP identities different from the session owner. This applies across CLI task and comment mutations (e.g., task create, task update, comment add), MCP task/comment tools (board_update_task, board_add_comment, legacy_comment), and the REST API (board_update_task, board_add_comment, and the legacy comment endpoint /api/board/comment). Write actions are now strictly tied to the authenticated user's session and the board's membership settings; no identity swap creates a separate write context.

Why write gating matters

Matching access semantics between reads and writes prevents accidental cross-board updates.
Boards with constrained visibility (Basic, Dimmed) can rely on a stable access model even when multiple identities are involved.
CLI, MCP, and REST workflows stay aligned: no identity switch or hidden flag can bypass board membership checks.
Auto-assign and auto-archive operations are restricted to the effective membership context; claims or leases cannot authorize actions outside the session owner's permissions.

You can read more about access control for downloads in the Images and Attachments documentation, which documents that files are only reachable for people who see the parent ticket.

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?

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

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

Browse features: Tasks
Appearance & AI Models