Repository navigation
[FEATURE]: TUI: Statuses via "flags" in current /Session view (feature option to create statuses, labels, etc) #30763
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
BLUF
A feature request for opencode to add user-defined session flags — lightweight status tags (todo, doing, done, blocked, etc.) defined in opencode.json. They can be applied to any session via a hotkey (%!) (just for example) or /flags, can be shown as colored chips in the session switcher, and browsable through a filtered "flags view" that groups sessions by flag. It replaces the current manual hack of typing [TODO]/[done] into session titles, giving you a fast, keyboard-driven way to mark sessions and come back to them — without the weight of a full kanban board.
**NOTE: Flags also can be commonly inferred as "labels" or "status" but giving more reconfigurable language to user.
EXAMPLE CONFIG:
Config (drop in opencode.json):
jsonc{
"$schema": "https://opencode.ai/config.json",
"session": {
"flags": [
{ "name": "todo", "key": "t", "color": "amber" },
{ "name": "doing", "key": "d", "color": "blue" },
{ "name": "done", "key": "o", "color": "green" },
{ "name": "blocked", "key": "b", "color": "red" },
{ "name": "review", "key": "r", "color": "purple" }
],
"flagsView": { "groupBy": "flag", "hideFlags": ["done"] }
}
}
Activity
github-actions commentedon Jun 4, 2026
This issue might be a duplicate of existing issues. Please check:
shuppel commentedon Jun 4, 2026
To github actions: this one is focused on the TUI but is also more open ended in terms of customization. This is a more lightweight and more malleable option to the previous feature suggested.
[-][FEATURE]: TUI: Statuses via "flags" (feature option for statuses)[/-][+][FEATURE]: TUI: Statuses via "flags" in current /Session view (feature option to create statuses, labels, etc)[/+]samuel-pro-ai commentedon Jun 12, 2026
+1 on this.
I have seen that a few related threads are piling up:
what I actually want day to day: a
groupByview on/sessions, by folder. similar to how file explorer or finder in mac works. Bonus if the folder pre-populates fromcwdso I'm not tagging every new session by hand. a "by status" group would be a bonus.sketch of the view I'd be happy with — collapsible headers in the existing list pane, not a permanent sidebar (a sidebar would eat the chat width and I don't want that):
config-wise I'd be fine with this — and I think folders (free string) and flags (enum) should stay separate, they pull in different directions. folders are cheap and informal, flags are workflow status:
{ "session": { "folders": { "auto": { "from": "cwd", "depth": 1 }, "manual": true }, "groupBy": "folder" } }bits worth calling out:
auto.from = "cwd"is the friction-killer. ~90% of my sessions would land in the right place with zero effortgroupByis a view toggle, not a per-session attribute. one keystroke (gorctrl+x g, whatever) to flip between grouped and flat/folder workto set,/folderto show,/folder -to clear,/foldersto list groupedif it helps scope the work I'd split it into two PRs:
foldercolumn, backfill old sessions tonull→ "Uncategorized", the four commands, the cwd auto-assign on session creationnothing else in the app needs to know about folders. backfill is a no-op, config is all optional with sensible defaults, and the flag work from this issue can land in parallel without touching the same column.
on my end I cobbled together a small plugin that approximates the workflow — set folder, list grouped, sidecar JSON at
~/.config/opencode/session-folders.json. happy to share if anyone wants to dogfood the UX before the TUI ships. I can also open the schema PR if it'd unblock this, but wanted to gut-check the design first.few things I'm genuinely not sure about:
tags: string[]field be simpler and let users decide semantics?auto.from = "cwd"be on by default or strictly opt-in? I could see existing users being surprised if folders start appearing out of nowhereshuppel commentedon Jun 14, 2026
@samuel-pro-ai thanks for pulling for related PRs for me and responding. This is great enrichment to the idea. I think there is a forward path to this and it's important that we make these as general.and configurable BECAUSE down the line could be context or graph rag related buildouts that could use that meta data at a relational level.
Part of me wants to fork to try and play with my own flavor but open code upgrades so much, it'd be too much for me to manage so would be optimal.if they could integrate it into their tool officially.
github-actions commentedon Aug 14, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.