fix(desktop): new-task composer draft disappears when switching projects in the workspace picker #3408

Closed
#3432
Closed
fix(desktop): new-task composer draft disappears when switching projects in the workspace picker#3408
#3432
Assignees
shaokeyibb
Labels
bugSomething isn't workinghelp wantedExtra attention is needed

Description

@me2seeks
me2seeks
opened on Aug 21, 2026

What happened

On the Desktop new-task surface, text typed into the session composer disappears when the target project is switched with the workspace picker below the composer. Switching back to No project restores the text — nothing is destroyed, but the draft silently swaps while the user is typing.

Expected: text already typed for a new task should remain visible when changing the target project before sending.

Root cause (from code inspection): since #3122 (93c65c7) the new-task composer draft slot is keyed by (profileId, hostId, projectId) — see newTaskDraftKey in apps/desktop/src/renderer/app-shell.tsx:245-253, wired as draftKey={activeId ?? newTaskDraftKey} in apps/desktop/src/renderer/chat-composer-region.tsx:154. When the key changes, the draft hook saves the current DOM text under the old key and loads the new key's slot (packages/ui/src/use-composer-draft.ts:102-116), which is empty for a freshly selected project — so the typed text vanishes from view. Before #3122 the key was the constant 'new-session', so project switches preserved the draft.

Per-project draft isolation may be intentional per #3122, so whether to carry text across resolved keys or keep scoped slots is a product decision — but the current behavior reads as data loss from the user's perspective.

How to reproduce

  1. Open the Desktop app and stay on the new-task (home) surface, no session active.
  2. Type some text into the composer.
  3. In the workspace picker below the composer, select any project.
  4. The typed text disappears from the composer.
  5. Select No project again — the text reappears.

Happens every time (deterministic renderer logic, not intermittent).

Environment

  • Maka version or commit: 57e08d8
  • OS and version: not captured by reporter; root cause is platform-independent renderer logic
  • Surface: Desktop

Logs, screenshots, or additional context

Code pointers:

  • Draft key includes projectId: apps/desktop/src/renderer/app-shell.tsx:245-253; consumed in apps/desktop/src/renderer/chat-composer-region.tsx:154.
  • Key-swap effect saves under the old key and loads the (empty) new slot: packages/ui/src/use-composer-draft.ts:102-116.
  • Picker callbacks that change only the selection state: apps/desktop/src/renderer/app-shell.tsx:1962 / :1970 → selectProject / selectNoProject in apps/desktop/src/renderer/use-new-task-target.ts.
  • Only the unresolved→resolved handoff moves text across keys (apps/desktop/src/renderer/chat-composer-region.tsx:83-107); there is no resolved→resolved carry-over, and no test covers switching between two resolved targets (apps/desktop/src/main/__tests__/chat-composer-region-draft-handoff.test.ts covers only the unresolved case).

Note: the text is retained in memory under the previous project's key, which is why selecting "No project" brings it back.

Disclosure: the reproduction steps were reported by a human user; the root-cause analysis above was prepared with assistance from a generative AI coding agent (code tracing only).

Metadata

Metadata

Assignees

Labels

bugSomething isn't workinghelp wantedExtra attention is needed

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    , 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
     blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

    Skip to content
    fix(desktop): new-task composer draft disappears when switching projects in the workspace picker #3408
    Closed
    #3432
    Closed
    fix(desktop): new-task composer draft disappears when switching projects in the workspace picker#3408
    #3432
    Assignees
    shaokeyibb
    Labels
    bugSomething isn't workinghelp wantedExtra attention is needed
    Description
    @me2seeks
    me2seeks
    opened on Aug 21, 2026
    What happened
    On the Desktop new-task surface, text typed into the session composer disappears when the target project is switched with the workspace picker below the composer. Switching back to No project restores the text — nothing is destroyed, but the draft silently swaps while the user is typing.
    Expected: text already typed for a new task should remain visible when changing the target project before sending.
    Root cause (from code inspection): since #3122 (93c65c7) the new-task composer draft slot is keyed by (profileId, hostId, projectId) — see newTaskDraftKey in apps/desktop/src/renderer/app-shell.tsx:245-253, wired as draftKey={activeId ?? newTaskDraftKey} in apps/desktop/src/renderer/chat-composer-region.tsx:154. When the key changes, the draft hook saves the current DOM text under the old key and loads the new key's slot (packages/ui/src/use-composer-draft.ts:102-116), which is empty for a freshly selected project — so the typed text vanishes from view. Before #3122 the key was the constant 'new-session', so project switches preserved the draft.
    Per-project draft isolation may be intentional per #3122, so whether to carry text across resolved keys or keep scoped slots is a product decision — but the current behavior reads as data loss from the user's perspective.
    How to reproduce
    1. Open the Desktop app and stay on the new-task (home) surface, no session active.
    2. Type some text into the composer.
    3. In the workspace picker below the composer, select any project.
    4. The typed text disappears from the composer.
    5. Select No project again — the text reappears.
    Happens every time (deterministic renderer logic, not intermittent).
    Environment
    • Maka version or commit: 57e08d8
    • OS and version: not captured by reporter; root cause is platform-independent renderer logic
    • Surface: Desktop
    Logs, screenshots, or additional context
    Code pointers:
    • Draft key includes projectId: apps/desktop/src/renderer/app-shell.tsx:245-253; consumed in apps/desktop/src/renderer/chat-composer-region.tsx:154.
    • Key-swap effect saves under the old key and loads the (empty) new slot: packages/ui/src/use-composer-draft.ts:102-116.
    • Picker callbacks that change only the selection state: apps/desktop/src/renderer/app-shell.tsx:1962 / :1970 → selectProject / selectNoProject in apps/desktop/src/renderer/use-new-task-target.ts.
    • Only the unresolved→resolved handoff moves text across keys (apps/desktop/src/renderer/chat-composer-region.tsx:83-107); there is no resolved→resolved carry-over, and no test covers switching between two resolved targets (apps/desktop/src/main/__tests__/chat-composer-region-draft-handoff.test.ts covers only the unresolved case).
    Note: the text is retained in memory under the previous project's key, which is why selecting "No project" brings it back.
    Disclosure: the reproduction steps were reported by a human user; the root-cause analysis above was prepared with assistance from a generative AI coding agent (code tracing only).
    Metadata
    Metadata
    Assignees
    Labels
    bugSomething isn't workinghelp wantedExtra attention is needed
    Type
    No type
    Projects
    No projects
      Milestone
      No milestone
      Relationships
      None yet
      Development
      No branches or pull requests
      Issue actions
      
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

      Skip to content
      fix(desktop): new-task composer draft disappears when switching projects in the workspace picker #3408
      Closed
      #3432
      Closed
      fix(desktop): new-task composer draft disappears when switching projects in the workspace picker#3408
      #3432
      Assignees
      shaokeyibb
      Labels
      bugSomething isn't workinghelp wantedExtra attention is needed
      Description
      @me2seeks
      me2seeks
      opened on Aug 21, 2026
      What happened
      On the Desktop new-task surface, text typed into the session composer disappears when the target project is switched with the workspace picker below the composer. Switching back to No project restores the text — nothing is destroyed, but the draft silently swaps while the user is typing.
      Expected: text already typed for a new task should remain visible when changing the target project before sending.
      Root cause (from code inspection): since #3122 (93c65c7) the new-task composer draft slot is keyed by (profileId, hostId, projectId) — see newTaskDraftKey in apps/desktop/src/renderer/app-shell.tsx:245-253, wired as draftKey={activeId ?? newTaskDraftKey} in apps/desktop/src/renderer/chat-composer-region.tsx:154. When the key changes, the draft hook saves the current DOM text under the old key and loads the new key's slot (packages/ui/src/use-composer-draft.ts:102-116), which is empty for a freshly selected project — so the typed text vanishes from view. Before #3122 the key was the constant 'new-session', so project switches preserved the draft.
      Per-project draft isolation may be intentional per #3122, so whether to carry text across resolved keys or keep scoped slots is a product decision — but the current behavior reads as data loss from the user's perspective.
      How to reproduce
      1. Open the Desktop app and stay on the new-task (home) surface, no session active.
      2. Type some text into the composer.
      3. In the workspace picker below the composer, select any project.
      4. The typed text disappears from the composer.
      5. Select No project again — the text reappears.
      Happens every time (deterministic renderer logic, not intermittent).
      Environment
      • Maka version or commit: 57e08d8
      • OS and version: not captured by reporter; root cause is platform-independent renderer logic
      • Surface: Desktop
      Logs, screenshots, or additional context
      Code pointers:
      • Draft key includes projectId: apps/desktop/src/renderer/app-shell.tsx:245-253; consumed in apps/desktop/src/renderer/chat-composer-region.tsx:154.
      • Key-swap effect saves under the old key and loads the (empty) new slot: packages/ui/src/use-composer-draft.ts:102-116.
      • Picker callbacks that change only the selection state: apps/desktop/src/renderer/app-shell.tsx:1962 / :1970 → selectProject / selectNoProject in apps/desktop/src/renderer/use-new-task-target.ts.
      • Only the unresolved→resolved handoff moves text across keys (apps/desktop/src/renderer/chat-composer-region.tsx:83-107); there is no resolved→resolved carry-over, and no test covers switching between two resolved targets (apps/desktop/src/main/__tests__/chat-composer-region-draft-handoff.test.ts covers only the unresolved case).
      Note: the text is retained in memory under the previous project's key, which is why selecting "No project" brings it back.
      Disclosure: the reproduction steps were reported by a human user; the root-cause analysis above was prepared with assistance from a generative AI coding agent (code tracing only).
      Metadata
      Metadata
      Assignees
      Labels
      bugSomething isn't workinghelp wantedExtra attention is needed
      Type
      No type
      Projects
      No projects
        Milestone
        No milestone
        Relationships
        None yet
        Development
        No branches or pull requests
        Issue actions
        
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

        Skip to content
        fix(desktop): new-task composer draft disappears when switching projects in the workspace picker #3408
        Closed
        #3432
        Closed
        fix(desktop): new-task composer draft disappears when switching projects in the workspace picker#3408
        #3432
        Assignees
        shaokeyibb
        Labels
        bugSomething isn't workinghelp wantedExtra attention is needed
        Description
        @me2seeks
        me2seeks
        opened on Aug 21, 2026
        What happened
        On the Desktop new-task surface, text typed into the session composer disappears when the target project is switched with the workspace picker below the composer. Switching back to No project restores the text — nothing is destroyed, but the draft silently swaps while the user is typing.
        Expected: text already typed for a new task should remain visible when changing the target project before sending.
        Root cause (from code inspection): since #3122 (93c65c7) the new-task composer draft slot is keyed by (profileId, hostId, projectId) — see newTaskDraftKey in apps/desktop/src/renderer/app-shell.tsx:245-253, wired as draftKey={activeId ?? newTaskDraftKey} in apps/desktop/src/renderer/chat-composer-region.tsx:154. When the key changes, the draft hook saves the current DOM text under the old key and loads the new key's slot (packages/ui/src/use-composer-draft.ts:102-116), which is empty for a freshly selected project — so the typed text vanishes from view. Before #3122 the key was the constant 'new-session', so project switches preserved the draft.
        Per-project draft isolation may be intentional per #3122, so whether to carry text across resolved keys or keep scoped slots is a product decision — but the current behavior reads as data loss from the user's perspective.
        How to reproduce
        1. Open the Desktop app and stay on the new-task (home) surface, no session active.
        2. Type some text into the composer.
        3. In the workspace picker below the composer, select any project.
        4. The typed text disappears from the composer.
        5. Select No project again — the text reappears.
        Happens every time (deterministic renderer logic, not intermittent).
        Environment
        • Maka version or commit: 57e08d8
        • OS and version: not captured by reporter; root cause is platform-independent renderer logic
        • Surface: Desktop
        Logs, screenshots, or additional context
        Code pointers:
        • Draft key includes projectId: apps/desktop/src/renderer/app-shell.tsx:245-253; consumed in apps/desktop/src/renderer/chat-composer-region.tsx:154.
        • Key-swap effect saves under the old key and loads the (empty) new slot: packages/ui/src/use-composer-draft.ts:102-116.
        • Picker callbacks that change only the selection state: apps/desktop/src/renderer/app-shell.tsx:1962 / :1970 → selectProject / selectNoProject in apps/desktop/src/renderer/use-new-task-target.ts.
        • Only the unresolved→resolved handoff moves text across keys (apps/desktop/src/renderer/chat-composer-region.tsx:83-107); there is no resolved→resolved carry-over, and no test covers switching between two resolved targets (apps/desktop/src/main/__tests__/chat-composer-region-draft-handoff.test.ts covers only the unresolved case).
        Note: the text is retained in memory under the previous project's key, which is why selecting "No project" brings it back.
        Disclosure: the reproduction steps were reported by a human user; the root-cause analysis above was prepared with assistance from a generative AI coding agent (code tracing only).
        Metadata
        Metadata
        Assignees
        Labels
        bugSomething isn't workinghelp wantedExtra attention is needed
        Type
        No type
        Projects
        No projects
          Milestone
          No milestone
          Relationships
          None yet
          Development
          No branches or pull requests
          Issue actions
          
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

          Skip to content
          fix(desktop): new-task composer draft disappears when switching projects in the workspace picker #3408
          Closed
          #3432
          Closed
          fix(desktop): new-task composer draft disappears when switching projects in the workspace picker#3408
          #3432
          Assignees
          shaokeyibb
          Labels
          bugSomething isn't workinghelp wantedExtra attention is needed
          Description
          @me2seeks
          me2seeks
          opened on Aug 21, 2026
          What happened
          On the Desktop new-task surface, text typed into the session composer disappears when the target project is switched with the workspace picker below the composer. Switching back to No project restores the text — nothing is destroyed, but the draft silently swaps while the user is typing.
          Expected: text already typed for a new task should remain visible when changing the target project before sending.
          Root cause (from code inspection): since #3122 (93c65c7) the new-task composer draft slot is keyed by (profileId, hostId, projectId) — see newTaskDraftKey in apps/desktop/src/renderer/app-shell.tsx:245-253, wired as draftKey={activeId ?? newTaskDraftKey} in apps/desktop/src/renderer/chat-composer-region.tsx:154. When the key changes, the draft hook saves the current DOM text under the old key and loads the new key's slot (packages/ui/src/use-composer-draft.ts:102-116), which is empty for a freshly selected project — so the typed text vanishes from view. Before #3122 the key was the constant 'new-session', so project switches preserved the draft.
          Per-project draft isolation may be intentional per #3122, so whether to carry text across resolved keys or keep scoped slots is a product decision — but the current behavior reads as data loss from the user's perspective.
          How to reproduce
          1. Open the Desktop app and stay on the new-task (home) surface, no session active.
          2. Type some text into the composer.
          3. In the workspace picker below the composer, select any project.
          4. The typed text disappears from the composer.
          5. Select No project again — the text reappears.
          Happens every time (deterministic renderer logic, not intermittent).
          Environment
          • Maka version or commit: 57e08d8
          • OS and version: not captured by reporter; root cause is platform-independent renderer logic
          • Surface: Desktop
          Logs, screenshots, or additional context
          Code pointers:
          • Draft key includes projectId: apps/desktop/src/renderer/app-shell.tsx:245-253; consumed in apps/desktop/src/renderer/chat-composer-region.tsx:154.
          • Key-swap effect saves under the old key and loads the (empty) new slot: packages/ui/src/use-composer-draft.ts:102-116.
          • Picker callbacks that change only the selection state: apps/desktop/src/renderer/app-shell.tsx:1962 / :1970 → selectProject / selectNoProject in apps/desktop/src/renderer/use-new-task-target.ts.
          • Only the unresolved→resolved handoff moves text across keys (apps/desktop/src/renderer/chat-composer-region.tsx:83-107); there is no resolved→resolved carry-over, and no test covers switching between two resolved targets (apps/desktop/src/main/__tests__/chat-composer-region-draft-handoff.test.ts covers only the unresolved case).
          Note: the text is retained in memory under the previous project's key, which is why selecting "No project" brings it back.
          Disclosure: the reproduction steps were reported by a human user; the root-cause analysis above was prepared with assistance from a generative AI coding agent (code tracing only).
          Metadata
          Metadata
          Assignees
          Labels
          bugSomething isn't workinghelp wantedExtra attention is needed
          Type
          No type
          Projects
          No projects
            Milestone
            No milestone
            Relationships
            None yet
            Development
            No branches or pull requests
            Issue actions
            
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

            Skip to content
            fix(desktop): new-task composer draft disappears when switching projects in the workspace picker #3408
            Closed
            #3432
            Closed
            fix(desktop): new-task composer draft disappears when switching projects in the workspace picker#3408
            #3432
            Assignees
            shaokeyibb
            Labels
            bugSomething isn't workinghelp wantedExtra attention is needed
            Description
            @me2seeks
            me2seeks
            opened on Aug 21, 2026
            What happened
            On the Desktop new-task surface, text typed into the session composer disappears when the target project is switched with the workspace picker below the composer. Switching back to No project restores the text — nothing is destroyed, but the draft silently swaps while the user is typing.
            Expected: text already typed for a new task should remain visible when changing the target project before sending.
            Root cause (from code inspection): since #3122 (93c65c7) the new-task composer draft slot is keyed by (profileId, hostId, projectId) — see newTaskDraftKey in apps/desktop/src/renderer/app-shell.tsx:245-253, wired as draftKey={activeId ?? newTaskDraftKey} in apps/desktop/src/renderer/chat-composer-region.tsx:154. When the key changes, the draft hook saves the current DOM text under the old key and loads the new key's slot (packages/ui/src/use-composer-draft.ts:102-116), which is empty for a freshly selected project — so the typed text vanishes from view. Before #3122 the key was the constant 'new-session', so project switches preserved the draft.
            Per-project draft isolation may be intentional per #3122, so whether to carry text across resolved keys or keep scoped slots is a product decision — but the current behavior reads as data loss from the user's perspective.
            How to reproduce
            1. Open the Desktop app and stay on the new-task (home) surface, no session active.
            2. Type some text into the composer.
            3. In the workspace picker below the composer, select any project.
            4. The typed text disappears from the composer.
            5. Select No project again — the text reappears.
            Happens every time (deterministic renderer logic, not intermittent).
            Environment
            • Maka version or commit: 57e08d8
            • OS and version: not captured by reporter; root cause is platform-independent renderer logic
            • Surface: Desktop
            Logs, screenshots, or additional context
            Code pointers:
            • Draft key includes projectId: apps/desktop/src/renderer/app-shell.tsx:245-253; consumed in apps/desktop/src/renderer/chat-composer-region.tsx:154.
            • Key-swap effect saves under the old key and loads the (empty) new slot: packages/ui/src/use-composer-draft.ts:102-116.
            • Picker callbacks that change only the selection state: apps/desktop/src/renderer/app-shell.tsx:1962 / :1970 → selectProject / selectNoProject in apps/desktop/src/renderer/use-new-task-target.ts.
            • Only the unresolved→resolved handoff moves text across keys (apps/desktop/src/renderer/chat-composer-region.tsx:83-107); there is no resolved→resolved carry-over, and no test covers switching between two resolved targets (apps/desktop/src/main/__tests__/chat-composer-region-draft-handoff.test.ts covers only the unresolved case).
            Note: the text is retained in memory under the previous project's key, which is why selecting "No project" brings it back.
            Disclosure: the reproduction steps were reported by a human user; the root-cause analysis above was prepared with assistance from a generative AI coding agent (code tracing only).
            Metadata
            Metadata
            Assignees
            Labels
            bugSomething isn't workinghelp wantedExtra attention is needed
            Type
            No type
            Projects
            No projects
              Milestone
              No milestone
              Relationships
              None yet
              Development
              No branches or pull requests
              Issue actions
              
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

              Skip to content
              fix(desktop): new-task composer draft disappears when switching projects in the workspace picker #3408
              Closed
              #3432
              Closed
              fix(desktop): new-task composer draft disappears when switching projects in the workspace picker#3408
              #3432
              Assignees
              shaokeyibb
              Labels
              bugSomething isn't workinghelp wantedExtra attention is needed
              Description
              @me2seeks
              me2seeks
              opened on Aug 21, 2026
              What happened
              On the Desktop new-task surface, text typed into the session composer disappears when the target project is switched with the workspace picker below the composer. Switching back to No project restores the text — nothing is destroyed, but the draft silently swaps while the user is typing.
              Expected: text already typed for a new task should remain visible when changing the target project before sending.
              Root cause (from code inspection): since #3122 (93c65c7) the new-task composer draft slot is keyed by (profileId, hostId, projectId) — see newTaskDraftKey in apps/desktop/src/renderer/app-shell.tsx:245-253, wired as draftKey={activeId ?? newTaskDraftKey} in apps/desktop/src/renderer/chat-composer-region.tsx:154. When the key changes, the draft hook saves the current DOM text under the old key and loads the new key's slot (packages/ui/src/use-composer-draft.ts:102-116), which is empty for a freshly selected project — so the typed text vanishes from view. Before #3122 the key was the constant 'new-session', so project switches preserved the draft.
              Per-project draft isolation may be intentional per #3122, so whether to carry text across resolved keys or keep scoped slots is a product decision — but the current behavior reads as data loss from the user's perspective.
              How to reproduce
              1. Open the Desktop app and stay on the new-task (home) surface, no session active.
              2. Type some text into the composer.
              3. In the workspace picker below the composer, select any project.
              4. The typed text disappears from the composer.
              5. Select No project again — the text reappears.
              Happens every time (deterministic renderer logic, not intermittent).
              Environment
              • Maka version or commit: 57e08d8
              • OS and version: not captured by reporter; root cause is platform-independent renderer logic
              • Surface: Desktop
              Logs, screenshots, or additional context
              Code pointers:
              • Draft key includes projectId: apps/desktop/src/renderer/app-shell.tsx:245-253; consumed in apps/desktop/src/renderer/chat-composer-region.tsx:154.
              • Key-swap effect saves under the old key and loads the (empty) new slot: packages/ui/src/use-composer-draft.ts:102-116.
              • Picker callbacks that change only the selection state: apps/desktop/src/renderer/app-shell.tsx:1962 / :1970 → selectProject / selectNoProject in apps/desktop/src/renderer/use-new-task-target.ts.
              • Only the unresolved→resolved handoff moves text across keys (apps/desktop/src/renderer/chat-composer-region.tsx:83-107); there is no resolved→resolved carry-over, and no test covers switching between two resolved targets (apps/desktop/src/main/__tests__/chat-composer-region-draft-handoff.test.ts covers only the unresolved case).
              Note: the text is retained in memory under the previous project's key, which is why selecting "No project" brings it back.
              Disclosure: the reproduction steps were reported by a human user; the root-cause analysis above was prepared with assistance from a generative AI coding agent (code tracing only).
              Metadata
              Metadata
              Assignees
              Labels
              bugSomething isn't workinghelp wantedExtra attention is needed
              Type
              No type
              Projects
              No projects
                Milestone
                No milestone
                Relationships
                None yet
                Development
                No branches or pull requests
                Issue actions
                
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

                Skip to content
                fix(desktop): new-task composer draft disappears when switching projects in the workspace picker #3408
                Closed
                #3432
                Closed
                fix(desktop): new-task composer draft disappears when switching projects in the workspace picker#3408
                #3432
                Assignees
                shaokeyibb
                Labels
                bugSomething isn't workinghelp wantedExtra attention is needed
                Description
                @me2seeks
                me2seeks
                opened on Aug 21, 2026
                What happened
                On the Desktop new-task surface, text typed into the session composer disappears when the target project is switched with the workspace picker below the composer. Switching back to No project restores the text — nothing is destroyed, but the draft silently swaps while the user is typing.
                Expected: text already typed for a new task should remain visible when changing the target project before sending.
                Root cause (from code inspection): since #3122 (93c65c7) the new-task composer draft slot is keyed by (profileId, hostId, projectId) — see newTaskDraftKey in apps/desktop/src/renderer/app-shell.tsx:245-253, wired as draftKey={activeId ?? newTaskDraftKey} in apps/desktop/src/renderer/chat-composer-region.tsx:154. When the key changes, the draft hook saves the current DOM text under the old key and loads the new key's slot (packages/ui/src/use-composer-draft.ts:102-116), which is empty for a freshly selected project — so the typed text vanishes from view. Before #3122 the key was the constant 'new-session', so project switches preserved the draft.
                Per-project draft isolation may be intentional per #3122, so whether to carry text across resolved keys or keep scoped slots is a product decision — but the current behavior reads as data loss from the user's perspective.
                How to reproduce
                1. Open the Desktop app and stay on the new-task (home) surface, no session active.
                2. Type some text into the composer.
                3. In the workspace picker below the composer, select any project.
                4. The typed text disappears from the composer.
                5. Select No project again — the text reappears.
                Happens every time (deterministic renderer logic, not intermittent).
                Environment
                • Maka version or commit: 57e08d8
                • OS and version: not captured by reporter; root cause is platform-independent renderer logic
                • Surface: Desktop
                Logs, screenshots, or additional context
                Code pointers:
                • Draft key includes projectId: apps/desktop/src/renderer/app-shell.tsx:245-253; consumed in apps/desktop/src/renderer/chat-composer-region.tsx:154.
                • Key-swap effect saves under the old key and loads the (empty) new slot: packages/ui/src/use-composer-draft.ts:102-116.
                • Picker callbacks that change only the selection state: apps/desktop/src/renderer/app-shell.tsx:1962 / :1970 → selectProject / selectNoProject in apps/desktop/src/renderer/use-new-task-target.ts.
                • Only the unresolved→resolved handoff moves text across keys (apps/desktop/src/renderer/chat-composer-region.tsx:83-107); there is no resolved→resolved carry-over, and no test covers switching between two resolved targets (apps/desktop/src/main/__tests__/chat-composer-region-draft-handoff.test.ts covers only the unresolved case).
                Note: the text is retained in memory under the previous project's key, which is why selecting "No project" brings it back.
                Disclosure: the reproduction steps were reported by a human user; the root-cause analysis above was prepared with assistance from a generative AI coding agent (code tracing only).
                Metadata
                Metadata
                Assignees
                Labels
                bugSomething isn't workinghelp wantedExtra attention is needed
                Type
                No type
                Projects
                No projects
                  Milestone
                  No milestone
                  Relationships
                  None yet
                  Development
                  No branches or pull requests
                  Issue actions