Skip to content

Fix project automation Qodo follow-ups#166

Open
friuns2 wants to merge 3 commits into
mainfrom
codex/project-automation-qodo-followups
Open

Fix project automation Qodo follow-ups#166
friuns2 wants to merge 3 commits into
mainfrom
codex/project-automation-qodo-followups

Conversation

@friuns2
Copy link
Copy Markdown
Owner

@friuns2 friuns2 commented May 12, 2026

Summary

  • refresh project automation state after project save/delete/remove flows
  • support TOML single-quoted cwd arrays and omit preserved TOML internals from automation API responses
  • add dark styling for sidebar automation chips and manual /automations regression coverage

Verification

  • pnpm vitest run src/server/codexAppServerBridge.inlinePayload.test.ts src/api/normalizers/v2.test.ts
  • pnpm run build:frontend

@qodo-free-for-open-source-projects
Copy link
Copy Markdown

Review Summary by Qodo

Harden project automation TOML parsing and API responses

✨ Enhancement 🐞 Bug fix

Grey Divider

Walkthroughs

Description
• Harden TOML array parsing to support single-quoted strings
• Omit internal TOML metadata from automation API responses
• Refresh project automations after save/delete operations
• Add dark theme styling for sidebar automation chips
Diagram
flowchart LR
  A["TOML Parser"] -->|"parse single-quoted arrays"| B["parseTomlStringArray()"]
  B -->|"create automation record"| C["parseAutomationToml()"]
  C -->|"filter internal metadata"| D["toAutomationApiRecord()"]
  D -->|"return to API"| E["API Endpoints"]
  F["Project Automation UI"] -->|"save/delete"| G["reloadProjectAutomations()"]
  G -->|"refresh state"| H["automationByProjectName"]
  H -->|"update all affected rows"| I["Sidebar Display"]
  J["Dark Theme"] -->|"apply styling"| K[".thread-row-automation-chip"]
Loading

Grey Divider

File Changes

1. src/server/codexAppServerBridge.ts ✨ Enhancement +76/-14

Harden TOML parsing and filter API responses

• Enhanced parseTomlStringArray() to parse single-quoted TOML strings without requiring JSON
 syntax
• Added toAutomationApiRecord(), toAutomationApiMap(), and toAutomationApiData() functions to
 filter out extraTomlLines from API responses
• Updated all automation API endpoints to use new filtering functions
• Exported parseAutomationToml() for testing

src/server/codexAppServerBridge.ts


2. src/server/codexAppServerBridge.inlinePayload.test.ts 🧪 Tests +48/-1

Add automation TOML parsing tests

• Added imports for parseAutomationToml and toAutomationApiRecord
• Added test for TOML single-quoted string array parsing with commas in values
• Added test verifying extraTomlLines is omitted from API records

src/server/codexAppServerBridge.inlinePayload.test.ts


3. src/components/sidebar/SidebarThreadTree.vue 🐞 Bug fix +10/-11

Refresh project automations after mutations

• Replaced direct state mutation with reloadProjectAutomations() function call after project
 automation save/delete
• Removed removeAutomationForProject() function in favor of full reload
• Updated onRemoveProject() to reload automations after deletion and emit change event
• Ensures all affected project rows refresh when multi-cwd automations are modified

src/components/sidebar/SidebarThreadTree.vue


View more (2)
4. src/style.css ✨ Enhancement +4/-0

Add dark theme automation chip styling

• Added dark theme styling for .thread-row-automation-chip class
• Uses amber color scheme with reduced opacity for dark mode readability

src/style.css


5. tests.md 📝 Documentation +33/-0

Add project automations regression test coverage

• Added comprehensive manual regression test suite for project automations feature
• Covers TOML single-quoted array parsing, multi-cwd automation updates, API response validation
• Includes light and dark theme verification steps
• Documents expected results and cleanup procedures

tests.md


Grey Divider

Qodo Logo

@qodo-free-for-open-source-projects
Copy link
Copy Markdown

qodo-free-for-open-source-projects Bot commented May 12, 2026

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (1)

Grey Divider


Action required

1. No performance audit documented 📘 Rule violation ➹ Performance
Description
This PR introduces behavior changes (new TOML array parsing and automation API response shaping)
without an accompanying measurement- or analysis-grounded performance audit. This risks unnoticed
regressions (e.g., payload bloat, extra requests, or slower routes) in the affected automation
flows.
Code

src/server/codexAppServerBridge.ts[R3275-3324]

function parseTomlStringArray(value: string): string[] {
const trimmed = value.trim()
if (!trimmed.startsWith('[') || !trimmed.endsWith(']')) return []
-  try {
-    const parsed = JSON.parse(trimmed)
-    return Array.isArray(parsed)
-      ? parsed.filter((item): item is string => typeof item === 'string' && item.trim().length > 0)
-      : []
-  } catch {
-    return []
+  const values: string[] = []
+  let index = 1
+  const endIndex = trimmed.length - 1
+
+  while (index < endIndex) {
+    while (index < endIndex && /[\s,]/u.test(trimmed[index] ?? '')) index += 1
+    if (index >= endIndex) break
+
+    const quote = trimmed[index]
+    if (quote !== '"' && quote !== "'") return []
+    const start = index
+    index += 1
+    let valueText = ''
+
+    if (quote === "'") {
+      const closeIndex = trimmed.indexOf("'", index)
+      if (closeIndex < 0 || closeIndex > endIndex) return []
+      valueText = trimmed.slice(index, closeIndex)
+      index = closeIndex + 1
+    } else {
+      let escaped = false
+      while (index < endIndex) {
+        const char = trimmed[index] ?? ''
+        if (escaped) {
+          escaped = false
+        } else if (char === '\\') {
+          escaped = true
+        } else if (char === '"') {
+          break
+        }
+        index += 1
+      }
+      if (index >= endIndex || trimmed[index] !== '"') return []
+      try {
+        valueText = JSON.parse(trimmed.slice(start, index + 1)) as string
+      } catch {
+        return []
+      }
+      index += 1
+    }
+
+    if (valueText.trim().length > 0) values.push(valueText)
+    while (index < endIndex && /\s/u.test(trimmed[index] ?? '')) index += 1
+    if (index < endIndex && trimmed[index] !== ',') return []
}
+
+  return values
Evidence
PR Compliance ID 7 requires an explicit performance audit for behavior changes; the diff adds new
parsing logic and changes API responses for automations, demonstrating a behavior change that should
be audited.

AGENTS.md
src/server/codexAppServerBridge.ts[3275-3324]
src/server/codexAppServerBridge.ts[7317-7444]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
PR Compliance ID 7 requires a performance audit for any feature/behavior change, grounded in measurements or explicit code-path analysis. This PR changes automation parsing and API response behavior, but does not include any performance-audit writeup.
## Issue Context
The changes affect automation listing/parsing and API payload shaping (potential request count/payload size/CPU parsing impacts). The audit should state what was measured (or why measurement wasn’t feasible) and include concrete results (e.g., request counts, response sizes, timing/profiler output) or a clear code-path analysis with next measurement steps.
## Fix Focus Areas
- src/server/codexAppServerBridge.ts[3275-3324]
- src/server/codexAppServerBridge.ts[3430-3451]
- src/server/codexAppServerBridge.ts[7317-7444]
- src/components/sidebar/SidebarThreadTree.vue[2267-2275]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Unhandled rejection on removal ✓ Resolved 🐞 Bug ☼ Reliability
Description
onRemoveProject() starts a deleteProjectAutomation().then(reloadProjectAutomations).finally(...)
chain without a catch, so any API/network failure will surface as an unhandled promise rejection and
can prevent state re-sync.
Code

src/components/sidebar/SidebarThreadTree.vue[R2267-2275]

const projectCwd = getProjectAutomationKey(projectName)
emit('remove-project', projectName)
if (projectCwd && projectHasAutomation(projectName)) {
-    void deleteProjectAutomation(projectCwd).catch(() => undefined)
  automationByProjectName.value = omitAutomationProject(automationByProjectName.value, projectCwd)
+    void deleteProjectAutomation(projectCwd)
+      .then(reloadProjectAutomations)
+      .finally(() => {
+        emit('automations-changed')
+      })
Evidence
The Sidebar code creates a promise chain without a catch, while the gateway delete method explicitly
throws on non-OK responses, meaning the chain can reject and become unhandled.

src/components/sidebar/SidebarThreadTree.vue[2266-2276]
src/api/codexGateway.ts[1217-1226]
src/api/codexGateway.ts[1132-1137]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`onRemoveProject()` triggers a fire-and-forget promise chain (`deleteProjectAutomation(...).then(reloadProjectAutomations).finally(...)`) without any `.catch(...)`. If the DELETE call fails or the subsequent reload fails, the promise rejects with no handler, leading to unhandled promise rejections and potentially leaving the UI automation state out of sync.
### Issue Context
- `deleteProjectAutomation()` throws when the HTTP response is not OK.
- `reloadProjectAutomations()` awaits `getProjectAutomationMap()`, which also throws on non-OK responses.
### Fix Focus Areas
- src/components/sidebar/SidebarThreadTree.vue[2266-2276]
### Suggested fix
Add an explicit `.catch(...)` to swallow/report errors, and consider reloading in a `finally`/best-effort path so the UI can reconcile state even when deletion fails.
Example (one option):

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

3. Project reload race 🐞 Bug ☼ Reliability ⭐ New
Description
reloadProjectAutomations() assigns automationByProjectName.value with the result of an async
fetch, but it’s triggered via fire-and-forget calls (void tryReloadProjectAutomations()) from
multiple user flows, allowing overlapping requests to apply out of order and overwrite newer state.
This can show stale automation chip counts/tooltips because the UI reads directly from
automationByProjectName.value.
Code

src/components/sidebar/SidebarThreadTree.vue[R2022-2033]

+async function reloadProjectAutomations(): Promise<void> {
+  automationByProjectName.value = await getProjectAutomationMap()
+}
+
+async function tryReloadProjectAutomations(): Promise<boolean> {
+  try {
+    await reloadProjectAutomations()
+    return true
+  } catch {
+    return false
+  }
+}
Evidence
The sidebar triggers non-awaited reloads and assigns the fetched map directly into the reactive
state with no ordering guard, while the same file demonstrates a version-guard pattern elsewhere to
prevent stale async writes; the automation chip count/tooltip reads from this same reactive state so
stale assignment becomes user-visible.

src/components/sidebar/SidebarThreadTree.vue[2022-2033]
src/components/sidebar/SidebarThreadTree.vue[2071-2081]
src/components/sidebar/SidebarThreadTree.vue[2090-2116]
src/components/sidebar/SidebarThreadTree.vue[1539-1546]
src/components/sidebar/SidebarThreadTree.vue[1321-1339]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Multiple code paths trigger `tryReloadProjectAutomations()` without awaiting or deduping, and `reloadProjectAutomations()` directly assigns to `automationByProjectName.value` when the request resolves. If two reloads overlap, an older response can resolve last and revert the UI to stale data.

## Issue Context
This component already uses a monotonic version guard (`pinnedThreadHydrationVersion`) to prevent out-of-order async state writes for pinned thread hydration.

## Fix Focus Areas
- src/components/sidebar/SidebarThreadTree.vue[2022-2033]
- src/components/sidebar/SidebarThreadTree.vue[2071-2081]
- src/components/sidebar/SidebarThreadTree.vue[2100-2116]
- src/components/sidebar/SidebarThreadTree.vue[1321-1339]

## Suggested fix
- Add a `projectAutomationReloadVersion` counter similar to `pinnedThreadHydrationVersion`.
- In `reloadProjectAutomations()`, capture `const version = ++projectAutomationReloadVersion`, await `getProjectAutomationMap()`, then only assign to `automationByProjectName.value` if `version === projectAutomationReloadVersion`.
- (Optional) Alternatively, serialize reloads by keeping a single in-flight promise and awaiting/chaining subsequent reload requests to it.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


4. Reload treated as save failure ✓ Resolved 🐞 Bug ≡ Correctness
Description
submitAutomationDialog() and onDeleteAutomationFromDialog() await reloadProjectAutomations() inside
the same try-block as the successful upsert/delete; if the refresh fails, the catch path runs, so
the UI reports a save/delete error and skips the success-path emit/notice even though the backend
mutation already succeeded.
Code

src/components/sidebar/SidebarThreadTree.vue[R2054-2060]

    ? await upsertProjectAutomation({ ...input, projectName })
    : await upsertThreadAutomation({ ...input, threadId })
  if (automationDialogScope.value === 'project') {
-      automationByProjectName.value = updateAutomationForProject(automationByProjectName.value, projectName, saved)
+      await reloadProjectAutomations()
  } else {
    automationByThreadId.value = updateAutomationForThread(automationByThreadId.value, threadId, saved)
  }
Evidence
The success path (emit + notice) is after await reloadProjectAutomations(), so any reload error
triggers the catch and prevents the success path from running; the reload can throw because the
gateway throws on non-OK responses.

src/components/sidebar/SidebarThreadTree.vue[2013-2068]
src/components/sidebar/SidebarThreadTree.vue[2071-2100]
src/api/codexGateway.ts[1132-1137]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Project automation save/delete paths treat the post-mutation refresh (`reloadProjectAutomations()`) as part of the mutation transaction. If the mutation succeeds but the refresh fails, the code falls into the catch block, sets an error, and does not run the success path (including `emit('automations-changed')` and success notices), leaving the UI inconsistent and misleading the user.
### Issue Context
- Upsert/delete occurs first, then `await reloadProjectAutomations()`.
- `reloadProjectAutomations()` depends on `getProjectAutomationMap()`, which throws on non-OK responses.
### Fix Focus Areas
- src/components/sidebar/SidebarThreadTree.vue[2013-2068]
- src/components/sidebar/SidebarThreadTree.vue[2071-2100]
### Suggested fix
Split the mutation and the refresh into separate try/catch blocks:
- If upsert/delete succeeds, run the success path (emit/notice/close/select).
- Attempt `reloadProjectAutomations()` as best-effort; if it fails, surface a non-blocking warning (or keep existing state) rather than reporting the mutation as failed.
Sketch:

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Previous review results

Review updated until commit cc7c112

Results up to commit N/A


🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0)


Action required
1. No performance audit documented 📘 Rule violation ➹ Performance
Description
This PR introduces behavior changes (new TOML array parsing and automation API response shaping)
without an accompanying measurement- or analysis-grounded performance audit. This risks unnoticed
regressions (e.g., payload bloat, extra requests, or slower routes) in the affected automation
flows.
Code

src/server/codexAppServerBridge.ts[R3275-3324]

function parseTomlStringArray(value: string): string[] {
 const trimmed = value.trim()
 if (!trimmed.startsWith('[') || !trimmed.endsWith(']')) return []
-  try {
-    const parsed = JSON.parse(trimmed)
-    return Array.isArray(parsed)
-      ? parsed.filter((item): item is string => typeof item === 'string' && item.trim().length > 0)
-      : []
-  } catch {
-    return []
+  const values: string[] = []
+  let index = 1
+  const endIndex = trimmed.length - 1
+
+  while (index < endIndex) {
+    while (index < endIndex && /[\s,]/u.test(trimmed[index] ?? '')) index += 1
+    if (index >= endIndex) break
+
+    const quote = trimmed[index]
+    if (quote !== '"' && quote !== "'") return []
+    const start = index
+    index += 1
+    let valueText = ''
+
+    if (quote === "'") {
+      const closeIndex = trimmed.indexOf("'", index)
+      if (closeIndex < 0 || closeIndex > endIndex) return []
+      valueText = trimmed.slice(index, closeIndex)
+      index = closeIndex + 1
+    } else {
+      let escaped = false
+      while (index < endIndex) {
+        const char = trimmed[index] ?? ''
+        if (escaped) {
+          escaped = false
+        } else if (char === '\\') {
+          escaped = true
+        } else if (char === '"') {
+          break
+        }
+        index += 1
+      }
+      if (index >= endIndex || trimmed[index] !== '"') return []
+      try {
+        valueText = JSON.parse(trimmed.slice(start, index + 1)) as string
+      } catch {
+        return []
+      }
+      index += 1
+    }
+
+    if (valueText.trim().length > 0) values.push(valueText)
+    while (index < endIndex && /\s/u.test(trimmed[index] ?? '')) index += 1
+    if (index < endIndex && trimmed[index] !== ',') return []
 }
+
+  return values
Evidence
PR Compliance ID 7 requires an explicit performance audit for behavior changes; the diff adds new
parsing logic and changes API responses for automations, demonstrating a behavior change that should
be audited.

AGENTS.md
src/server/codexAppServerBridge.ts[3275-3324]
src/server/codexAppServerBridge.ts[7317-7444]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
PR Compliance ID 7 requires a performance audit for any feature/behavior change, grounded in measurements or explicit code-path analysis. This PR changes automation parsing and API response behavior, but does not include any performance-audit writeup.
## Issue Context
The changes affect automation listing/parsing and API payload shaping (potential request count/payload size/CPU parsing impacts). The audit should state what was measured (or why measurement wasn’t feasible) and include concrete results (e.g., request counts, response sizes, timing/profiler output) or a clear code-path analysis with next measurement steps.
## Fix Focus Areas
- src/server/codexAppServerBridge.ts[3275-3324]
- src/server/codexAppServerBridge.ts[3430-3451]
- src/server/codexAppServerBridge.ts[7317-7444]
- src/components/sidebar/SidebarThreadTree.vue[2267-2275]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Unhandled rejection on removal ✓ Resolved 🐞 Bug ☼ Reliability
Description
onRemoveProject() starts a deleteProjectAutomation().then(reloadProjectAutomations).finally(...)
chain without a catch, so any API/network failure will surface as an unhandled promise rejection and
can prevent state re-sync.
Code

src/components/sidebar/SidebarThreadTree.vue[R2267-2275]

 const projectCwd = getProjectAutomationKey(projectName)
 emit('remove-project', projectName)
 if (projectCwd && projectHasAutomation(projectName)) {
-    void deleteProjectAutomation(projectCwd).catch(() => undefined)
   automationByProjectName.value = omitAutomationProject(automationByProjectName.value, projectCwd)
+    void deleteProjectAutomation(projectCwd)
+      .then(reloadProjectAutomations)
+      .finally(() => {
+        emit('automations-changed')
+      })
Evidence
The Sidebar code creates a promise chain without a catch, while the gateway delete method explicitly
throws on non-OK responses, meaning the chain can reject and become unhandled.

src/components/sidebar/SidebarThreadTree.vue[2266-2276]
src/api/codexGateway.ts[1217-1226]
src/api/codexGateway.ts[1132-1137]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`onRemoveProject()` triggers a fire-and-forget promise chain (`deleteProjectAutomation(...).then(reloadProjectAutomations).finally(...)`) without any `.catch(...)`. If the DELETE call fails or the subsequent reload fails, the promise rejects with no handler, leading to unhandled promise rejections and potentially leaving the UI automation state out of sync.
### Issue Context
- `deleteProjectAutomation()` throws when the HTTP response is not OK.
- `reloadProjectAutomations()` awaits `getProjectAutomationMap()`, which also throws on non-OK responses.
### Fix Focus Areas
- src/components/sidebar/SidebarThreadTree.vue[2266-2276]
### Suggested fix
Add an explicit `.catch(...)` to swallow/report errors, and consider reloading in a `finally`/best-effort path so the UI can reconcile state even when deletion fails.
Example (one option):

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended
3. Reload treated as save failure ✓ Resolved 🐞 Bug ≡ Correctness
Description
submitAutomationDialog() and onDeleteAutomationFromDialog() await reloadProjectAutomations() inside
the same try-block as the successful upsert/delete; if the refresh fails, the catch path runs, so
the UI reports a save/delete error and skips the success-path emit/notice even though the backend
mutation already succeeded.
Code

src/components/sidebar/SidebarThreadTree.vue[R2054-2060]

     ? await upsertProjectAutomation({ ...input, projectName })
     : await upsertThreadAutomation({ ...input, threadId })
   if (automationDialogScope.value === 'project') {
-      automationByProjectName.value = updateAutomationForProject(automationByProjectName.value, projectName, saved)
+      await reloadProjectAutomations()
   } else {
     automationByThreadId.value = updateAutomationForThread(automationByThreadId.value, threadId, saved)
   }
Evidence
The success path (emit + notice) is after await reloadProjectAutomations(), so any reload error
triggers the catch and prevents the success path from running; the reload can throw because the
gateway throws on non-OK responses.

src/components/sidebar/SidebarThreadTree.vue[2013-2068]
src/components/sidebar/SidebarThreadTree.vue[2071-2100]
src/api/codexGateway.ts[1132-1137]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Project automation save/delete paths treat the post-mutation refresh (`reloadProjectAutomations()`) as part of the mutation transaction. If the mutation succeeds but the refresh fails, the code falls into the catch block, sets an error, and does not run the success path (including `emit('automations-changed')` and success notices), leaving the UI inconsistent and misleading the user.
### Issue Context
- Upsert/delete occurs first, then `await reloadProjectAutomations()`.
- `reloadProjectAutomations()` depends on `getProjectAutomationMap()`, which throws on non-OK responses.
### Fix Focus Areas
- src/components/sidebar/SidebarThreadTree.vue[2013-2068]
- src/components/sidebar/SidebarThreadTree.vue[2071-2100]
### Suggested fix
Split the mutation and the refresh into separate try/catch blocks:
- If upsert/delete succeeds, run the success path (emit/notice/close/select).
- Attempt `reloadProjectAutomations()` as best-effort; if it fails, surface a non-blocking warning (or keep existing state) rather than reporting the mutation as failed.
Sketch:

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Qodo Logo

Comment on lines 3275 to +3324
function parseTomlStringArray(value: string): string[] {
const trimmed = value.trim()
if (!trimmed.startsWith('[') || !trimmed.endsWith(']')) return []
try {
const parsed = JSON.parse(trimmed)
return Array.isArray(parsed)
? parsed.filter((item): item is string => typeof item === 'string' && item.trim().length > 0)
: []
} catch {
return []
const values: string[] = []
let index = 1
const endIndex = trimmed.length - 1

while (index < endIndex) {
while (index < endIndex && /[\s,]/u.test(trimmed[index] ?? '')) index += 1
if (index >= endIndex) break

const quote = trimmed[index]
if (quote !== '"' && quote !== "'") return []
const start = index
index += 1
let valueText = ''

if (quote === "'") {
const closeIndex = trimmed.indexOf("'", index)
if (closeIndex < 0 || closeIndex > endIndex) return []
valueText = trimmed.slice(index, closeIndex)
index = closeIndex + 1
} else {
let escaped = false
while (index < endIndex) {
const char = trimmed[index] ?? ''
if (escaped) {
escaped = false
} else if (char === '\\') {
escaped = true
} else if (char === '"') {
break
}
index += 1
}
if (index >= endIndex || trimmed[index] !== '"') return []
try {
valueText = JSON.parse(trimmed.slice(start, index + 1)) as string
} catch {
return []
}
index += 1
}

if (valueText.trim().length > 0) values.push(valueText)
while (index < endIndex && /\s/u.test(trimmed[index] ?? '')) index += 1
if (index < endIndex && trimmed[index] !== ',') return []
}

return values
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. No performance audit documented 📘 Rule violation ➹ Performance

This PR introduces behavior changes (new TOML array parsing and automation API response shaping)
without an accompanying measurement- or analysis-grounded performance audit. This risks unnoticed
regressions (e.g., payload bloat, extra requests, or slower routes) in the affected automation
flows.
Agent Prompt
## Issue description
PR Compliance ID 7 requires a performance audit for any feature/behavior change, grounded in measurements or explicit code-path analysis. This PR changes automation parsing and API response behavior, but does not include any performance-audit writeup.

## Issue Context
The changes affect automation listing/parsing and API payload shaping (potential request count/payload size/CPU parsing impacts). The audit should state what was measured (or why measurement wasn’t feasible) and include concrete results (e.g., request counts, response sizes, timing/profiler output) or a clear code-path analysis with next measurement steps.

## Fix Focus Areas
- src/server/codexAppServerBridge.ts[3275-3324]
- src/server/codexAppServerBridge.ts[3430-3451]
- src/server/codexAppServerBridge.ts[7317-7444]
- src/components/sidebar/SidebarThreadTree.vue[2267-2275]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment thread src/components/sidebar/SidebarThreadTree.vue
@friuns2
Copy link
Copy Markdown
Owner Author

friuns2 commented May 12, 2026

Performance audit for the automation follow-up changes:

  • Ran focused API smoke against isolated CODEX_HOME on local dev server.
  • Endpoint measured: GET /codex-api/project-automations.
  • Request count: 1.
  • Response size: 282 bytes for seeded cron automation with preserved TOML table metadata.
  • Local elapsed time: 16.84 ms.
  • Verified no extraTomlLines leaked in the response.
  • Verified single-quoted TOML cwds parsed and listed correctly.

Additional verification:

  • pnpm vitest run src/server/codexAppServerBridge.inlinePayload.test.ts src/api/normalizers/v2.test.ts: 16 tests passed.
  • pnpm run build:frontend: passed.

@friuns2
Copy link
Copy Markdown
Owner Author

friuns2 commented May 12, 2026

/review

@qodo-free-for-open-source-projects
Copy link
Copy Markdown

qodo-free-for-open-source-projects Bot commented May 12, 2026

Persistent review updated to latest commit cc7c112

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants