Views and workspaces

Views and workspaces

Tables you come back to every day, objects you keep opening, and groups of clusters you switch between can be saved and reached in one click. Everything here lives in Sextant's settings on your computer; nothing is written to a cluster.

Contents: Saved views · Favourites (pins) · Workspaces · Managing them · Export and import · What is never exported · When a context is renamed or deleted

Saved views

A view is a resource table saved under a name, such as "Failing pods in shop" or "Ingresses of team-a". It keeps:

• the kind (Pods, Deployments, a custom resource…);
• the namespaces of the namespace filter;
• the search text;
• Only problems (for kinds that have it);
• a label selector, such as app=web,tier!=db — it is sent to the cluster with the watch, so only matching objects are listed;
• the sort column and direction;
• which columns are shown (the Columns menu in the table header hides and shows them).

To save one, set the table up and press Save view in its header. Give it a Name, choose Show in: This cluster or All clusters (a view for every cluster, useful for "Pods with problems"), change the Label selector if you like, and tick Pin to favourites to put it on the strip as well.

Open a view from:

• the Views list above the sections of a cluster (the views of this cluster and those for all clusters);
• the command palette (Ctrl+K / Cmd+K), under Saved views;
• a pin.

Opening a view switches to its cluster if needed (connecting it, as clicking its icon would) and restores the table exactly as saved. A table with a label selector shows it above the rows, with a button to remove it.

Favourites (pins)

The Favourites strip above the sections holds pinned objects and views of the open cluster.

• Pin an object: Pin to favourites in its actions (in the table's row menu, the details panel or the command palette). It opens the object's details in its cluster. Unpin from favourites removes it.
• Pin a view: the pin button next to a view in the Views list, or Pin to favourites when saving it.
• Pins also appear in the command palette under Favourites.

Pinning changes nothing in the cluster. A pinned object that was deleted from the cluster stays on the strip until you unpin it.

Workspaces

A workspace is a named set of clusters, such as "prod" or "staging". The workspace button at the top of the cluster rail shows the current one:

• All clusters shows every cluster (the default);
• choosing a workspace shows only its clusters in the rail (the cluster you have open stays visible), and the command palette offers only their views and pins;
• Manage workspaces… creates, edits and deletes them.

Switching a workspace never connects or disconnects a cluster. Clusters outside the workspace keep their connections, port forwards and shells; they are only hidden from the rail.

Managing them

Views and workspaces opens from the button next to the Views heading (Manage views and workspaces) or from Manage workspaces… in the workspace menu. It has three tabs:

Tab	What you can do
Views	Rename, move up and down, delete. Deleting a view also removes its pins. A view whose cluster no longer exists says Cluster not found.
Workspaces	New workspace, choose its clusters, rename, Use, delete. Deleting a workspace keeps its clusters, views and pins.
Export and import	See below.

Limits: 500 views, 500 pins, 100 workspaces; names up to 120 characters.

Export and import

Export… writes a JSON file with your views, pins and workspaces, and the clusters they belong to by reference: the kubeconfig file path and the context name. It also carries the clusters' shareable settings: display name, colour, icon, namespace filter and Preview changes. Tick Include agent access rules to add each cluster's MCP agent access rules as well; they are left out otherwise. Include terminal snippets (ticked by default) adds your terminal snippets; they are exported exactly as written, so do not keep tokens or passwords in them.

Import… opens a file chooser and reads only the file you pick (at most 1 MiB). Nothing is saved until you confirm:

1. The file is checked strictly: an unknown field or a wrong value is reported by name and nothing is imported.
2. The Preview lists each section — Clusters, Views, Pins, Workspaces, Snippets — with each entry as Added, Changed, Unchanged, Skipped or Missing on this computer.
3. Each cluster of the file is matched to one of yours: Same kubeconfig file and context (an exact match), or Matched by the context name only: it may be another cluster. A cluster with no match is listed as missing; Sextant never creates clusters or kubeconfig entries. Views and pins of a missing cluster are skipped.
4. Replace entries that differ from mine decides what happens to changed entries and cluster settings: without it, yours stay.
5. Apply the agent access rules from the file is off by default. Agent access rules decide what AI agents may do in a cluster, so apply them only from a file you trust. They are never applied to a cluster matched by name only, whatever you tick.
6. A changed or added snippet is shown with its command, spaces and hidden characters made visible (Here now: and From the file:); a snippet with control, invisible or text-direction characters is refused.
7. Import saves what the preview listed.

Files exported by Sextant 0.13 (version 1) are still imported; they have no snippets.

Sharing a file with a colleague works best when you both use the same kubeconfig paths and context names; otherwise its clusters show as missing.

What is never exported

An export file never contains:

• the contents of a kubeconfig, server certificates, credentials, tokens or passwords;
• Secret values;
• the MCP server's token or settings;
• extensions or the permissions you granted them;
• agent access rules, unless you ticked Include agent access rules;
• terminal snippets, if you untick Include terminal snippets;
• notification, window and other application settings.

When a context is renamed or deleted

A cluster is identified by its kubeconfig file and context name. When you rename a context in Sextant (Kubeconfig management), its views, pins and place in workspaces move to the new name with its other settings. When you delete a context in Sextant, they are deleted with it, so a new context with the same name later starts clean. If a context is renamed outside Sextant (with kubectl config rename-context, say), Sextant sees a new cluster, and the old cluster's views show Cluster not found.