Gemini session project unknown and incorrect User event

[cdeil]

For my Gemini CLI sessions they all show under "unknown" - it seems the project folder/name isn't inferred correctly.

Also I see some "User" entries in the session view which looks like Gemini talking to sub-agents or itself, it's not a prompt I as user entered.

See example:

[wesm]

thanks, I'll look into this today

[cdeil]

I still see some Gemini sessions as unknown. I'm not opening a new issue since I'm not sure if it can be inferred. Here's what agent analysis claims:

---

Why some Gemini sessions show as "unknown":

The "unknown" you're seeing is the project name, not the agent type. In discovery.go:466, when a Gemini tmp/ subdirectory is an old-format SHA-256 hash that isn't found in ~/.gemini/projects.json, the project resolves to "unknown". This happens when:

The Gemini CLI cleaned up projects.json but left session files behind
The session was created in a directory that no longer has an entry in projects.json
PR #39 added Gemini support, but can't fix the project name if the mapping data (projects.json) is missing. Those sessions parse correctly as Gemini agent — they just don't have a resolvable project name.

[wesm]

Did you resync?

[wesm]

Try clicking the options cog in the top right to request a resync, that should fix it but if it does not please provide more detail and I can investigate

[cdeil]

I have the same result after re-sync and also after rm -r ~/.agentsview and re-start.

The problem is with the Gemini importer - see agent analysis below.

Not sure what to do here, maybe these could be options you could consider:

1. filtering out empty sessions (0 messages) by default or offering an option for users like me that have "dirty" histories but want "clean" view on agentsview
2. none of the options the agent suggests could be done for Gemini seem attractive to me. Maybe again just offer a power-user option to allow me to filter out "unknown" projects or old projects/sessions with incomplete information to get a cleaner view.

---

"Unknown" Project Sessions

35 sessions have project = "unknown": 33 Gemini + 2 Codex.

Root cause

Gemini CLI stores session files under ~/.gemini/tmp/<dir>/chats/. In older versions, <dir> is a SHA-256 hash of the absolute working directory path. The mapping from hash to path is stored in ~/.gemini/projects.json, but this file only contains currently active projects (4 in your case). Old entries get cleaned up by Gemini CLI, leaving orphan hash directories with no way to resolve their project name.

The resolveGeminiProject() function in internal/sync/discovery.go returns "unknown" when a 64-char hex directory name isn't found in projects.json.

Newer Gemini CLI versions use the project name directly as the directory name (e.g., ~/.gemini/tmp/agentsview/), which always resolves correctly.

The 33 Gemini sessions — all identified

By computing SHA-256 hashes of known paths and extracting file path references from session content, all 13 orphan hash directories were identified:

Hash prefix	Sessions	Actual project path	Method
17721799...	1	/Users/cdeil/code/learn/learn-playwright-python	Hash match (dir exists)
41162ca9...	2	/Users/cdeil/code/projects/cocopilot	Hash match (dir exists)
7a1ca186...	3	/Users/cdeil/code/stocadro/backend_fastapi_2	Hash match (dir exists)
17926b1c...	3	/Users/cdeil/code/stocadro/frontend_flutter	Hash match (dir exists)
e5837200...	1	/Users/cdeil/code/stocadro/stocadro-academy	Hash match (dir exists)
36ea6801...	1	/Users/cdeil/code/stocadro/stocadro-ai	Hash match (dir exists)
dd9fa602...	1	/Users/cdeil/code/stocadro/stocadro-chatbot	Hash match (dir exists)
f888ee54...	8	/Users/cdeil/code/learn/gemini-training	Hash verified from session content
134ccf53...	1	/Users/cdeil/code/learn/gemini-training/exercises/python	Hash verified from session content
5fe96625...	3	/Users/cdeil/code/learn/gemini-training/my-task-manager	Hash verified from session content
77c7bdbc...	4	/Users/cdeil/code/learn/gemini-training/config-test	Hash verified from session content
5dff87f0...	1	/Users/cdeil/PycharmProjects/FastAPIProject	Hash verified from session content
127c9ffa...	4	Unknown (deleted dir?) — sessions are casual/testing ("hi", "joke", screenshot questions)	Content analysis; no dir match found

These paths exist on disk but aren't in projects.json because Gemini CLI removed them when the projects were no longer recently active.

The 2 Codex sessions

Both are empty sessions (message_count = 0) from Aug 2025. Codex sessions store the working directory in the JSONL file; these have cwd set to a path whose last component is "unknown". These are invisible in the UI since the session list filters out message_count = 0.

Could agentsview fix this?

Partially. Two approaches:

1. Read trustedFolders.json — This file lists additional project paths that aren't in projects.json. Computing their hashes would resolve some orphans. However, it also gets cleaned up over time.

2. Brute-force hash reversal — Scan common directories (e.g., ~/code/, ~/Projects/) and compute hashes to match against orphan dirs. This is what we did above, and it works for directories that still exist on disk. The downside is it's slow and requires scanning the filesystem.

3. Extract from session content — Some Gemini sessions contain file path references in tool call results that reveal the working directory. This is fragile and requires parsing message content.

The fundamental limitation is that Gemini's old-format hash directories are a one-way function (SHA-256). Once projects.json loses the mapping, the only ways to recover the path are: the directory still exists (brute-force), session content contains path references (fragile), or the user remembers.

[wesm]

Thanks for the extra information, taking a closer look at this

[wesm]

I took another swing at this with #44, I'll release this soon or you can try the dev version and let me know if it resolves the issue you're having. I don't have any misbehaving Gemini session data to be able to test myself

[wesm]

I believe this is fixed now, especially after #58. please reopen after upgrading and resyncing if you still see issues! cutting the next release presently