Fixing SSR Cookie Handling & Daily JS Call Machine Issues — September 2, 2026

Today, I set out to tackle two pressing issues that have been impacting the functionality of my platform. I focused on fixing the SSR cookie handling for anonymous requests and resolving the loading issues with the daily JS call machine. Both of these fixes were crucial to ensuring that the user experience on the agentic web remains seamless and efficient. I spent about an hour on these fixes, which, while not extensive, were critical to maintaining the integrity of the system.

The first fix I implemented was related to the gp_theme cookie and its handling during server-side rendering (SSR). The issue was that the shared nginx page caches were not varying based on the gp_theme cookie for anonymous requests. This oversight allowed a single dark/space visitor to inadvertently bake a dark-variant page that was then served to everyone else. To address this, I made sure that the gp_theme cookie would not be SSR'd for anonymous requests. This was a necessary cache-poison guard to prevent unintended theming for users who had not explicitly selected their preferences. It took a bit of digging into the caching logic to understand how the nginx configurations were set up, but I’m confident this fix will enhance the user experience significantly.

The second fix focused on the daily JS call machine. I discovered that the enforced Content Security Policy (CSP) was blocking the use of unsafe-eval for loading the daily-js call machine bundle. This was causing every Tavus portal call to fail at the join stage, effectively breaking the functionality for users attempting to access the portal. I modified the loading mechanism to utilize the dailyConfig.avoidEval parameter, which eliminates the need for eval() altogether. This change not only resolves the immediate issue but also aligns with best practices for security, as it reduces potential vulnerabilities associated with eval(). The fix was straightforward but required careful testing to ensure that the call machine loaded correctly without compromising the security policies.

Reflecting on these fixes, it’s clear that maintaining a one-man-show like this requires constant vigilance. Each bug fix not only improves the platform but also teaches me something new about the architecture. Working solo means I have to wear many hats, and while it can be exhausting, it’s also incredibly rewarding. I often find that the most challenging bugs end up being the most educational. Today’s work reinforced the importance of understanding how different components interact, particularly in a complex system like the agentic web.

I chose to tackle these issues without relying on external tools or additional team members. Instead, I used Claude Code in VS Code, which has become my go-to setup for coding. I appreciate the autonomy it provides, allowing me to experiment and iterate quickly. This approach not only keeps costs down but also aligns with my vision of building a billion-dollar company as a solo developer. It’s a grind to manage everything, but each fix brings me closer to that goal.

As I move forward, I’ll keep my focus on optimizing the user experience and ensuring that the platform runs smoothly. I’ve learned that even small fixes can have a significant impact on performance and user satisfaction. Tomorrow, I plan to dive deeper into the portal CRM features and explore how I can further enhance the user interface and functionality. The journey is long, but every step is a step toward creating a robust agentic web that empowers users.

In summary, today’s focus on fixing SSR cookie handling and the daily JS call machine has not only resolved critical issues but has also reinforced my commitment to building a reliable and secure platform. I’m excited to see how these changes will improve the overall experience for users engaging with the agentic web. As always, I’ll continue to document this journey, sharing both the successes and the challenges, as I work toward my ambitious vision.